測試面試題總結(jié)及問題解析

計算機網(wǎng)絡（tcp/ip詳解卷1、謝希仁的計算機網(wǎng)絡）、數(shù)據(jù)庫（sql必知必會、數(shù)據(jù)庫案例

應用）、操作系統(tǒng)（現(xiàn)代操作系統(tǒng)、清華的公開課）、數(shù)據(jù)結(jié)構(gòu)和算法（劍指offer、大話

數(shù)據(jù)結(jié)構(gòu)、leetcode只做了一點、還有?？蜕系乃惴ㄕn）、java語言（java程序員面試寶

典、java程序員的基本修養(yǎng)、大話設(shè)計模式只看了重要的）、測試相關(guān)（軟件測試的藝術(shù)、

從菜鳥到測試架構(gòu)師、軟件測試技術(shù)大全、selenium,qtp,junit的-一些相關(guān)資料和書）、linux

看了一點（鳥哥的私房菜基礎(chǔ)篇和網(wǎng)絡篇）?？傊芏鄸|西是看完就忘，我是邊看會在。nenote

記筆記，忘了就回去翻筆記和書再看看。

——摘自?？湍澄淮笊竦目偨Y(jié)

因為沒有對知識點進行分類，所以我在每個問題后面加上了標簽，表示屬于哪本書，如果這

個看的還不明白就翻對應的書或者我給的博客鏈接看看，后面的星星表示知識點的重要程

度，我大概是根據(jù)面試被問及的次數(shù)標記的，僅供參考。問題是我整理別人的面經(jīng)還有我自

己的一些面經(jīng)，答案是我從書上或者一些博客上找的，所以我只是一個搬運工哈哈哈

計算機網(wǎng)絡

計算機網(wǎng)絡里面socket通信常用的函數(shù)叫啥？

Socket：網(wǎng)絡上的兩個程序通過一個雙向的通信連接實現(xiàn)數(shù)據(jù)的交換，根據(jù)連接啟動的方

式以及本地套接字要連接的目標，套接字之間的連接過程可以分為三個步驟：服務器監(jiān)聽，

客戶端請求，連接確認。

（1）服務器監(jiān)聽：服務器端套接字并不定位具體的客戶端套接字，而是處于等待連接

的狀態(tài)，實時監(jiān)控網(wǎng)絡狀態(tài)。

（2）客戶端請求：由客戶端的套接字提出連接請求，要連接的目標是服務器端的套接

字。為此，客戶端的套接字必須首先描述它要連接的服務器的套接字，指出服務器端套接字

的地址和端口號，然后就向服務器端套接字提出連接請求。

（3）連接確認：是指當服務器端套接字監(jiān)聽到或者說接收到客戶端套接字的連接請求,

它就響應客戶端套接字的請求，建立一個新的線程，把服務器端套接字的描述發(fā)給客戶端，

一旦客戶端確認了此描述，連接就建立好了。而服務器端套接字繼續(xù)處于監(jiān)聽狀態(tài)，繼續(xù)接

收其他客戶端套接字的連接請求。

常用的函數(shù)：

1.創(chuàng)建：socket。函數(shù)，這個操作類似于打開文件操作，返回socket的socket描述符。

2.綁定：bind。函數(shù)，把一個地址族的特定地址指定給socket,而不是由系統(tǒng)隨機分配.

3.listen。、connect。函數(shù)，客戶端通過調(diào)用connect函數(shù)來建立與TCP服務器的連接。

服務器端調(diào)用listen。，socket開始等待客戶的鏈接請求

4.accept。函數(shù)，服務器收到請求后，用accept接受請求，然后鏈接就建立了，可以開

始讀寫操作。

5.read。,write。讀寫操作

6.close。函數(shù)，讀寫完畢后要關(guān)閉相應的socket描述字

TCP//A

S?rv?r

UDP方式

ServerClient

輸入一個URL到看到結(jié)果，啰輸入網(wǎng)址到顯示網(wǎng)頁的過程，涉及了哪些

協(xié)議。（計算機網(wǎng)絡）

DNS解析一＞建立連接

發(fā)送數(shù)據(jù)包服務器響應請求

返回給瀏覽器-＞瀏覽器渲染程序頁面。

1.DNS解析

當我搜索這個問題的時候，首先在瀏覽器輸入了一個URL地址，但URL中服務器地址

是一個域名而不是一個指定的IP地址，路由器并不知道你想要查找的地址，那么DNS域名

解析系統(tǒng)會將該域名解析成ip，而IP地址是唯一的，每一個ip地址對應網(wǎng)絡上的一臺計

算機。

2.建立網(wǎng)絡連接，發(fā)送數(shù)據(jù)包

由于1的努力，已經(jīng)能夠根據(jù)ip和端口號與網(wǎng)絡上對應的服務器建立連接，瀏覽器這

邊會向服務器發(fā)送一個數(shù)據(jù)包，里面包含了大量的信息，但這個數(shù)據(jù)包有一定的格式。就像

我給你郵個快遞，也得遵循郵遞公司的一些規(guī)則吧！我得寫上我的身份信息、寄的物品、標

明郵遞地址….道理是一樣的，到了網(wǎng)絡中這些規(guī)則就是“H即協(xié)議（網(wǎng)絡協(xié)議廣。

HTTP是一個屬于應用層的面向?qū)ο蟮膮f(xié)議，HTTP協(xié)議一共有五大特點：1、支持客戶/

服務器模式（C/S模式）；2、簡單快速；3、靈活；4、無連接；5、無狀態(tài)。

無連接

無連接咬義是限制每次連接只處理一個請求。服務器處理完客戶的請求，并收到客戶的應

答后，艮1*下連接。采用這種方式可以節(jié)省傳輸時間。

早期這么做的原因是HTTP協(xié)議產(chǎn)生于互聯(lián)網(wǎng)，因此服務器需要處理同時面向全世界數(shù)十

萬、上百萬客戶端的網(wǎng)頁訪問，但每個客戶端（即瀏覽器）與服務器之間交換數(shù)據(jù)的間歇性

較大（即傳輸具有突發(fā)性、瞬時性），并且網(wǎng)頁瀏覽的聯(lián)想性、發(fā)散性導致兩次傳送的數(shù)據(jù)

關(guān)聯(lián)性很低，大部分通道實際上會很空閑、無端占用資源。因此HTTP的設(shè)計者有意利用

這種特點將協(xié)議設(shè)計為請求時建連接、請求完釋放連接，以盡快將資源釋放出來服務其他客

戶端。隨著時間的推移，網(wǎng)頁變得越來越復雜，里面可能嵌入了很多圖片，這時候每次訪問

圖片都需要建立一次TCP連接就顯得很低效。后來，Keep-Alive被提出用來解決這效率低

的問題。

Keep-Alive功能使客戶端到服務器端的連接持續(xù)有效（長連接），當出現(xiàn)對服務器的后繼

請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包

括iPlanet、1IS和Apache,都支持HTTPKeep-Aliveo對于提供靜態(tài)內(nèi)容的網(wǎng)站來說，這

個功能通常很有用。但是，對于負擔較重的網(wǎng)站來說，這里存在另外一個問題：雖然為客戶

保留打開的連接有一定的好處，但它同樣影響了性能，因為在處理暫停期間，本來可以釋放

的資源仍舊被占用。當Web服務器和應用服務器在同一臺機器上運行時，Keep-Alive功能

對資源利用的影響尤其突出。這樣一來，客戶端和服務器之間的HTTP連接就會被保持，

不會斷開（超過Keep-Alive規(guī)定的時間，意外斷電等情況除外），當客戶端發(fā)送另外一個

請求時，就使用這條已經(jīng)建立的連接.

無狀態(tài)

★

無狀態(tài)是指協(xié)議對于事務處理沒有記憶能力，服務器不知道客戶端是什么狀態(tài)。即我們給服

務器發(fā)送HTTP請求之后，服務器根據(jù)請求，會給我們發(fā)送數(shù)據(jù)過來，但是，發(fā)送完，不

會記錄任何信息。HTTP是一個無狀態(tài)協(xié)議，這意味著每個請求都是獨立的，Keep-Alive沒

能改變這個結(jié)果。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能

導致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務器不需要先前信息時它的應答就較快。

HTTP協(xié)議這種特性有優(yōu)點也有缺點，優(yōu)點在于解放了服務器，每一次請求“點到為止”不會

造成不必要連接占用，缺點在于每次請求會傳輸大量重復的內(nèi)容信息。

客戶端與服務器進行動態(tài)交互的Web應用程序出現(xiàn)之后，HTTP無狀態(tài)的特性嚴重阻礙了

這些應用程序的實現(xiàn)，畢竟交互是需要承前啟后的，簡單的購物車程序也要知道用戶到底在

之前選擇了什么商品。于是，兩種用于保持HTTP連接狀態(tài)的技術(shù)就應運而生了，一個是

Cookie,而另一個則是Session?☆禽

Cookie

可以保持登錄信息到用戶下次與服務器的會話，換句話說，下次訪問同一網(wǎng)站時，用戶會發(fā)

現(xiàn)不必輸入用戶名和密碼就已經(jīng)登錄了（當然，不排除用戶手工刪除Cookie）o而還有一

些Cookie在用戶退出會話的時候就被刪除了，這樣可以有效保護個人隱私。

Cookies最典型的應用是判定注冊用戶是否已經(jīng)登錄網(wǎng)站，用戶可能會得到提示，是否在下

一次進入此網(wǎng)站時保留用戶信息以便簡化登錄手續(xù)，這些都是Cookies的功用。另一個重

要應用場合是“購物車''之類處理。用戶可能會在一段時間內(nèi)在同一家網(wǎng)站的不同頁面中選擇

不同的商品，這些信息都會寫入Cookies,以便在最后付款時提取信息。

Session

它是通過服務器來保持狀態(tài)的。

當客戶端訪問服務器時，服務器根據(jù)需求設(shè)置Session,將會話信息保存在服務器上，同時

將標示Session的Sessionld傳遞給客戶端瀏覽器，瀏覽器將這個Sessionld保存在內(nèi)存

中，我們稱之為無過期時間的Cookieo瀏覽器關(guān)閉后，這個Cookie就會被清掉，它不會

存在于用戶的Cookie臨時文件。以后瀏覽器每次請求都會額外加上這個參數(shù)值，服務器會

根據(jù)這個Sessionld,就能取得客戶端的數(shù)據(jù)信息。

如果客戶端瀏覽器意外關(guān)閉，服務器保存的Session數(shù)據(jù)不是立即釋放，此時數(shù)據(jù)還會存

在，只要我們知道那個Sessionld,就可以繼續(xù)通過請求獲得此Session的信息，因為此時

后臺的Session還存在，當然我們可以設(shè)置一個Session超時時間，一旦超過規(guī)定時間沒

有客戶端請求時，服務器就會清除對應Sessionld的Session信息。

什么是http協(xié)議？它的主要內(nèi)容。

http協(xié)議（超文本傳輸協(xié)議）是客戶端和服務器端兩者通信共同遵循的一些規(guī)則。

主要內(nèi)容是定義了客戶端如何向服務器請求資源，服務器如何響應客戶端請求。

請求中的POST與GET方法有什么區(qū)別？★★

1.根據(jù)HTTP規(guī)范，GET用于信息獲取，而且應該是安全的，這里的安全是指非修改的

信息，就像在數(shù)據(jù)庫執(zhí)行查詢一樣，不會修改數(shù)據(jù)，也不會增加刪減數(shù)據(jù)，不會影響資源的

狀態(tài)，而post可能會改變數(shù)據(jù)的原始狀態(tài)。

2.GET提交的數(shù)據(jù)最多只有1024字節(jié)，理論上POST是沒有限制的。

3.從請求的URL中可以找到一個區(qū)別：GET請求的數(shù)據(jù)會附在URL之后，在瀏覽器

URL欄就能看的。似乎POST比GET更可靠一些，因為它請求把提交的數(shù)據(jù)放在包體中，

地址欄上不可見。（也有的解釋說兩者都沒有長度限制，根本的區(qū)別就是一個是獲取數(shù)據(jù)，

一個修改數(shù)據(jù)！）

HTTP定義了與服務器交互的不同方法，最基本的方法是GET和POST.

HTTP-GET和HTTP-POST是使用HTTP的標準協(xié)議動詞，用于編碼和傳送變量名/變

量值對參數(shù)，并且使用相關(guān)的請求語義。每個HTTP-GET和HTTP-POST都由一系列HTTP

請求頭組成，這些請求頭定義了客戶端從服務器請求了什么，而響應則是由一系列HTTP

應答頭和應答數(shù)據(jù)組成，如果請求成功則返回應答。

HTTP-GET以使用MIME類型application/x-www-form-urlencoded的urlencoded文本的

格式傳遞參數(shù)。Urlencoding是一種字符編碼，保證被傳送的參數(shù)由遵循規(guī)范的文本組成，

例如一個空格的編碼是“％20”。附加參數(shù)還能被認為是一個查詢字符串。

與HTTP-GET類似，HTTP-POST參數(shù)也是被URL編碼的。然而，變量名/變量值不作

為URL的一部分被傳送，而是放在實際的HTTP請求消息內(nèi)部被傳送。

（1）get是從服務器上獲取數(shù)據(jù)，post是向服務器傳送數(shù)據(jù)。

（1）在客戶端，Get方式在通過URL提交數(shù)據(jù)，數(shù)據(jù)在URL中可以看到；POST方

式，數(shù)據(jù)放置在HTMLHEADER內(nèi)提交。

（2）對于get方式，服務器端用Request.QueryString獲取變量的值,對于post方式,

服務器端用Request.Fonn獲取提交的數(shù)據(jù)。

（2）GET方式提交的數(shù)據(jù)最多只能有1024字節(jié)，而POST則沒有此限制。

（3）安全性問題。正如在（1）中提到，使用Get的時候，參數(shù)會顯示在地址欄上，

而Post不會。所以，如果這些數(shù)據(jù)是中文數(shù)據(jù)而且是非敏感數(shù)據(jù)，那么使用get：如果用戶

輸入的數(shù)據(jù)不是中文字符而且包含敏感數(shù)據(jù)，那么還是使用post為好。

注:所謂的安全意味著該操作用于獲取信息而非修改信息。幕等的意味著對同一URL的

多個請求應該返回同樣的結(jié)果。完整的定義并不像看起來那樣嚴格。換句話說，GET請求

一般不應產(chǎn)生副作用。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的

角度來看沒有改變資源。比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一

批新聞，該操作仍然被認為是安全的和幕等的，因為它總是返回當前的新聞。反之亦然。

POST請求就不那么輕松了。POST表示可能改變服務器上的資源的請求。仍然以新聞站點

為例，讀者對文章的注解應該通過POST請求實現(xiàn)，因為在注解提交之后站點已經(jīng)不同了（比

方說文章下面出現(xiàn)一條注解）。

3.服務器響應請求，返回給瀏覽器

服務器會分解你的數(shù)據(jù)包，例如你查找的是一個文檔，那么服務器可能會返回一個doc

文檔或者zip壓縮資源給你；如果你訪問的是一個鏈接頁面，那么服務器相應的返回一個包

含HTML/CSS標記文檔，這些請求和響應都有一個通用的寫法，這些規(guī)則也就是前面提到

的"http協(xié)議

客戶端向服務器請求資源時，除了告訴服務器要請求的資源，同時還會附帶一些其他的

信息，這部分信息放在"header”部分（服務器響應請求也一樣?。?，主要有請求頭（略）和響

應頭，這里以響應頭部信息為例：

http響應狀態(tài)碼：

狀態(tài)碼的職責是當客戶端向服務器端發(fā)送請求時，描述返回的請求結(jié)果。借助于狀態(tài)碼，瀏

覽器（或者說用戶）可以知道服務器是正常的處理了請求，還是出現(xiàn)了錯誤。

數(shù)字的第一位指定了響應類型，后兩位無分類。響應類別一共有5種：

1XXInformational（信息性狀態(tài)碼）

2XXSuccess（成功狀態(tài)碼）

3XXRedirection（重定向狀態(tài)碼）

4XXClientError（客戶端錯誤狀態(tài)碼）

5XXServerError（服務器錯誤狀態(tài)碼）

HTTP響應狀態(tài)碼有很多，但是實際經(jīng)常使用的大概只有14個。

2XXSuccess

200OK表示從客戶端發(fā)來的請求在服務器端被正常處理了。

204NoContent該狀態(tài)碼表示服務器接收的請求已成功處理，但在返回的響應報文中不含實

體的主體部分。比如，當從瀏覽器發(fā)出請求處理后，返回204響應，那么瀏覽器顯示的頁面

不發(fā)生更新。

206PartialContent該狀態(tài)碼表示客戶端進行了范圍請求，而服務器成功執(zhí)行了這部分的

GET請求。

3XXRedirection

301MovedPermanently永久性重定向。該狀態(tài)碼表示請求的資源己經(jīng)被分配了新的URL

以后應使用資源現(xiàn)在所指的URI。像下方給出的請求URI,當指定的資源路徑的最后忘記

添加斜杠就會產(chǎn)生301狀態(tài)碼

302Found臨時性重定向。該狀態(tài)碼表示請求的資源已被分配了新的UR1,希望用戶（本次）

能使用新的URI訪問。

303SeeOther該狀態(tài)碼表示由于請求對應的資源存在另外一個URI,應使用GET方法定向

獲取請求的資源。303狀態(tài)碼和302狀態(tài)碼有著相同的功能，但303狀態(tài)碼明確表明客戶

端應當采用GET方法獲取資源。當301,302,303響應狀態(tài)碼返回時，幾乎所有的瀏覽器

都會把POST改成GET,并刪除請求報文的主體，之后請求會自動再次發(fā)送。301,302標

準是禁止將POST方法改變成GET方法的，但實際上使用時大家都會這么做。

304NotModified該狀態(tài)碼表示客戶端發(fā)送附帶條件的請求時，服務器端允許請求訪問資源，

但未滿足條件的情況。304狀態(tài)碼返回時，不包含任何響應的主體部分。304雖然被劃分在

3XX類別中，但是和重定向沒有關(guān)系。

307TemporaryRedirect臨時重定向。該狀態(tài)碼與302Found有著相同的含義。307會遵照瀏

覽器標準，不會從POST變成GET。

4XXClientError

400BadRequest該狀態(tài)碼表示請求報文中存在語法錯誤。當錯誤發(fā)生時，需要修改請求的

內(nèi)容后再次放松請求。

401Unauthorized該狀態(tài)碼表示發(fā)送的請求需要有通過HTTP認證的認證信息，另外若之前

已進行過1此請求，則表示用戶認證失敗。

403Forbidden該狀態(tài)碼表明對請求資源的訪問被服務器拒絕了。

404NotFound該狀態(tài)碼表明服務器上無法找到請求的資源。除此之外，也可以在服務器端

拒絕請求且不想說明理由時使用。

5XXServerError

500InternalServerError該狀態(tài)碼表明服務器端在執(zhí)行請求時發(fā)生了錯誤。

503ServiceUnavailable該狀態(tài)碼表明服務器暫時處于超負載或正在進行停機維護，現(xiàn)在無

法處理請求

常見狀態(tài)碼☆★

100Continue繼續(xù)，一般在發(fā)送post請求時，已發(fā)送了hllp、header之后服務端

將返回此信息，表示確認，之后發(fā)送具體參數(shù)信息

200OK正常返回信息

201Created請求成功并且服務器創(chuàng)建了新的資源

301MovedPermanently請求的網(wǎng)頁已永久移動到新位置。

400BadRequest服務器無法理解請求的格式，客戶端不應當嘗試再次使用相同的

內(nèi)容發(fā)起請求。

404NotFound找不到如何與URI相匹配的資源。

500InternalServerError最常見的服務器端錯誤。

4.瀏覽器渲染呈現(xiàn)

瀏覽器拿到響應的頁面代碼，將其解析呈現(xiàn)在用戶面前，至于為什么會是看到的這個

樣子，有時又是另外的一些頁面效果，這里就涉及到web標準了，也就是我們經(jīng)常提到的

w3c標準。根據(jù)資源的類型，在網(wǎng)頁上呈現(xiàn)給用戶，這個過程叫網(wǎng)頁渲染。解析和呈現(xiàn)的過

程主要由瀏覽器的渲染引擎實現(xiàn)，瀏覽器的渲染引擎質(zhì)量就決定了瀏覽器的好壞（引擎這一

塊已經(jīng)超出了我的理解范圍了）。

但實際上輸入URL到頁面呈現(xiàn)這背后涉及的內(nèi)容遠遠不止這些，例如后臺web服務

器、雙向的網(wǎng)絡數(shù)據(jù)傳輸、http緩存策略等

涉及協(xié)議：

（1）應用層HTTP（www訪問協(xié)議），DNS（域名解析服務）

（2）傳輸層TCP（為HTTP提供可靠的數(shù)據(jù)傳輸），UDP（DNS使用UDP傳輸）

（3）網(wǎng)絡層：IP（IP數(shù)據(jù)包傳輸和路由選擇），ICMP（提供網(wǎng)絡傳輸過程中的差錯檢測），

ARP（將本機的默認網(wǎng)關(guān)IP地址映射成物理MAC地址）

TCP與UDP的區(qū)別、應用（計算機網(wǎng)絡）★★

1）TCP（TransmissionControlProtocol,傳輸控制協(xié)議）是基于連接的協(xié)議，在正式收發(fā)數(shù)

據(jù)前，必須和對方建立可靠的連接。一個TCP連接必須要經(jīng)過三次握手才能建立起來。

2）TCP提供可靠的數(shù)據(jù)傳輸服務，通信進程能夠依靠TCP無差錯、有序交付所有數(shù)據(jù)。

3）TCP具有擁塞控制機制，該服務在發(fā)送方和接收方之間的網(wǎng)絡出現(xiàn)擁塞時，抑制發(fā)送進

程。這可能會導致進程通信變慢，但是對網(wǎng)絡整體通信有好處。

UDP（UserDataProtocol,用戶數(shù)據(jù)報協(xié)議）是與TCP相對應的協(xié)議。

1）它是面向非連接的協(xié)議，它不與對方建立連接，而是直接就把數(shù)據(jù)包發(fā)送過去！（延時

?。?/p>

2）UDP提供不可靠數(shù)據(jù)傳輸服務，不保證報文到達，也不保證有序到達。這種不可靠數(shù)據(jù)

傳輸服務包括進程間的數(shù)據(jù)交付和差錯檢查兩種服務，是運輸層協(xié)議實現(xiàn)的最低限度服務。

3）UDP沒有擁塞控制機制，所以UDP可以用I他選定的任何速率向下層（網(wǎng)絡層）傳輸數(shù)

據(jù)（速度有保證）。

綜合以上大致可以得出兩者的適用應用：UDP適用于對可靠性要求不高的應用環(huán)境，但是

對數(shù)據(jù)傳輸速率有最小限制且對延時有要求，例如因特網(wǎng)電話。TCP適用于對數(shù)據(jù)傳輸可

靠性要求較高的應用，web的HTTP協(xié)議就使用TCP進行數(shù)據(jù)傳輸。

UDP相對TCP的優(yōu)勢：

（1）無延時。只要應用進程將數(shù)據(jù)傳遞給UDP,UDP就會將此數(shù)據(jù)打包進UDP報文段并

立即傳遞給網(wǎng)絡層。但是TCP可能會因為擁塞阻塞機制阻止運輸層TCP發(fā)送方，并且一直

等待，直到可以發(fā)送，這會增加時延。對實時應用，少量數(shù)據(jù)損耗并不影響，但延時不能太

大，這最好使用UDP,如網(wǎng)絡電話。

（2）UDP無需連接建立，相比TCP節(jié)省了三次握手時間。DNS使用UDP協(xié)、議，主要是因

為UDP不需要建立連接，節(jié)省了握手時間，如果運行在TCP上，DNS會很慢。

（3）UDP無連接狀態(tài)，而TCP需要維護連接狀態(tài)，這包括維持一些參數(shù)，因此使用UDP

可以使服務器同時支持更多用戶。

（4）分組開銷小，UDP使用8字節(jié)首部開銷（各兩字節(jié)：源端口號、目的端口號、長度、

檢驗和），TCP使用20字節(jié)首部開銷。

TCP三次握手和四次揮手（計算機網(wǎng)絡）★★★

三次握手的過程:

ClientServer

LISTEN

(listen())

SYNRCVD

ESTABLISHED

(write())

(read())

陽

馳

s與

郭

墩

苑

三次握手的過程：

第一次握手：建立連接。客戶端發(fā)送連接請求報文段，將SYN位置為1,SequenceNumber

為x；然后，客戶端進入SYN_SEND狀態(tài)，等待服務器的確認；

第二次握手：服務器收到SYN報文段。服務器收到客戶端的SYN報文段，需要對這個SYN

報文段進行確認，設(shè)置AcknowledgmentNumber為x+l(SequenceNumber+1)；同時，自己自

己還要發(fā)送SYN請求信息，將SYN位置為1,SequenceNumber為y；服務器端將上述所

有信息放到一個報文段(即SYN+ACK報文段)中，一并發(fā)送給客戶端，此時服務器進入

SYN_RECV狀態(tài)；

第三次握手：客戶端收到服務器的SYN+ACK報文段。然后將AcknowledgmentNumber設(shè)

置為y+1,向服務器發(fā)送ACK報文段，這個報文段發(fā)送完畢以后，客戶端和服務器端都進

入ESTABLISHED狀態(tài)，完成TCP三次握手。

完成了三次握手，客戶端和服務器端就可以開始傳送數(shù)據(jù)。

四次揮手的過程：

第一次揮手：主機1（可以使客戶端，也可以是服務器端），設(shè)置SequenceNumber和

AcknowledgmentNumber.向主機2發(fā)送一個FIN報文段；此時，主機1進入FIN_WAIT_1

狀態(tài)；這表示主機1沒有數(shù)據(jù)要發(fā)送給主機2了；

第二次揮手：主機2收到了主機1發(fā)送的FIN報文段，向主機1回一個ACK報文段，

AcknowledgmentNumber為SequenceNumber加1；主機1進入FIN_WAIT_2狀態(tài)；主機2

告訴主機1,我“同意“你的關(guān)閉請求；

第三次揮手：主機2向主機1發(fā)送FIN報文段，請求關(guān)閉連接，同時主機2進入LAST_ACK

狀態(tài)；

第四次揮手：主機1收到主機2發(fā)送的FIN報文段，向主機2發(fā)送ACK報文段，然后主機

1進入TIME_WAIT狀態(tài)；主機2收到主機1的ACK報文段以后，就關(guān)閉連接；此時，主

機1等待2MSL后依然沒有收到回復，則證明Server端已正常關(guān)閉，那好，主機1也可以

關(guān)閉連接了。

為什么要三次握手？★★

client發(fā)出的第一個連接請求報文段并沒有丟失，而是在某個網(wǎng)絡結(jié)點長時間的滯留了，以

致延誤到連接釋放以后的某個時間才到達server。本來這是一個早已失效的報文段。但server

收到此失效的連接請求報文段后，就誤認為是client再次發(fā)出的一個新的連接請求。于是就

向client發(fā)出確認報文段，同意建立連接。假設(shè)不采用“三次握手”，那么只要server發(fā)出確

認，新的連接就建立了。由于現(xiàn)在client并沒有發(fā)出建立連接的請求，因此不會理睬server

的確認，也不會向server發(fā)送數(shù)據(jù)。但server卻以為新的運輸連接已經(jīng)建立，并一直等待

client發(fā)來數(shù)據(jù)。這樣，server的很多資源就白白浪費掉了。采用“三次握手”的辦法可以防止

上述現(xiàn)象發(fā)生。防止了服務器端的一直等待而浪費資源。

為什么要四次揮手？★

?FIN_WAIT」：這個狀態(tài)要好好解釋一下，其實FIN_WAIT_1和FIN_WAIT_2狀態(tài)

的真正含義都是表示等待對方的FIN報文。而這兩種狀態(tài)的區(qū)別是：FIN_WAIT_1

狀態(tài)實際上是當SOCKET在ESTABLISHED狀態(tài)時，它想主動關(guān)閉連接，向?qū)Ψ桨l(fā)

送了FIN報文，此時該SOCKET即進入到FIN_WAIT_1狀態(tài)。而當對方回應ACK

報文后，則進入到FIN_WAIT_2狀態(tài)，當然在實際的正常情況下，無論對方何種情

況下，都應該馬上回應ACK報文，所以FIN_WAIT」狀態(tài)一般是比較難見到的，

而FIN_WAIT_2狀態(tài)還有時常?？梢杂胣etstat看到。（主動方）

?FIN_WAIT_2：上面已經(jīng)詳細解釋了這種狀態(tài)，實際上FIN_WAIT_2狀態(tài)下的

SOCKET,表示半連接，也即有一方要求close連接，但另外還告訴對方，我暫時還

有點數(shù)據(jù)需要傳送給你（ACK信息），稍后再關(guān)閉連接。（主動方）

?CLOSE_WAIT：這種狀態(tài)的含義其實是表示在等待關(guān)閉。怎么理解呢？當對方close

一個SOCKET后發(fā)送FIN報文給自己，你系統(tǒng)毫無疑問地會回應一個ACK報文給

對方，此時則進入到CLOSE_WAIT狀態(tài)。接下來呢，實際上你真正需要考慮的事

情是察看你是否還有數(shù)據(jù)發(fā)送給對方，如果沒有的話，那么你也就可以close這個

SOCKET,發(fā)送FIN報文給對方，也即關(guān)閉連接。所以你在CLOSE_WAIT狀態(tài)下，

需要完成的事情是等待你去關(guān)閉連接。（被動方）

?LAST.ACK:這個狀態(tài)還是比較容易好理解的，它是被動關(guān)閉一方在發(fā)送FIN報文

后，最后等待對方的ACK報文。當收至IjACK報文后，也即可以進入到CLOSED

可用狀態(tài)了。（被動方）

?TIME.WAIT:表示收到了對方的FIN報文，并發(fā)送出了ACK報文，就等2MSL后

即可回到CLOSED可用狀態(tài)了。如果FINWAIT1狀態(tài)下，收到了對方同時帶FIN

標志和ACK標志的報文時，可以直接進入到TIME_WAIT狀態(tài)，而無須經(jīng)過

FIN_WAIT_2狀態(tài)。（主動方）

?CLOSED:表示連接中斷。

常見使用TCP協(xié)議的應用如下:

食☆

瀏覽器用的HTTP

FlashFXP用的FTP

Outlook用的POP、SMTP

Putty用的Telnet、SSH

QQ文件傳輸

常見使用UDP協(xié)議的應用如下：

QQ語音、QQ視頻、TFTP、DNS

表5-1使用UDP和TCP協(xié)議的各種應用和應用層協(xié)議

應用應用層協(xié)議運輸層協(xié)議

名字轉(zhuǎn)換DNSUDP

文件傳送TFTPUDP

路由選擇協(xié)議RIPUDP

IP地址配置BOOTP,DHCPUDP

網(wǎng)絡管理SNMPUDP

遠程文件服務器NFSUDP

IP電話專用協(xié)議UDP

流式多媒體通信專用協(xié)議UDP

多播IGMPUDP

電子郵件SMTPTCP

遠程終端接入TELNETTCP

萬維網(wǎng)HTTPTCP

文件傳送____________FTPTCP

TCP數(shù)據(jù)包結(jié)構(gòu)（計算機網(wǎng)絡）

1-1.源始端口16位，范圍當然是0-65535啦。

1-2.目的端口，同上。

2-1.數(shù)據(jù)序號32位，TCP為發(fā)送的每個字節(jié)都編一個號碼，這里存儲當前數(shù)據(jù)包數(shù)據(jù)第一

個字節(jié)的序號。

3-1.確認序號32位，為了安全，TCP告訴接受者希望他下次接到數(shù)據(jù)包的第一個字節(jié)的序

號。

4-1.偏移4位，類似IP,表明數(shù)據(jù)距包頭有多少個32位。

4-2.保留6位，未使用，應置零。

4-3.緊急比特URG-當URG=1時，表明緊急指針字段有效。它告訴系統(tǒng)此報文段中有緊

急數(shù)據(jù)，應盡快傳送(相當于高優(yōu)先級的數(shù)據(jù))。

4-3.確認比特ACK—只有當ACK=1時確認號字段才有效。當ACK=0時，確認號無效。

4-4.復位比特RST(Reset)—當RST=1時，表明TCP連接中出現(xiàn)嚴重差錯(如由于主機崩潰

或其他原因)，必須釋放連接，然后再重新建立運輸連接。

4-5.同步比特SYN—同步比特SYN置為1,就表示這是一個連接請求或連接接受報文。參

考TCP三次握手

4-6.終止比特FIN(FINal)—用來釋放一個連接。當FIN=1時，表明此報文段的發(fā)送端的數(shù)

據(jù)已發(fā)送完畢，并要求釋放運輸連接。

4-7.窗口字段16位，窗口字段用來控制對方發(fā)送的數(shù)據(jù)量，單位為字節(jié)。TCP連接的一端

根據(jù)設(shè)置的緩存空間大小確定自己的接收窗口大小，然后通知對方以確定對方的發(fā)送窗口的

上限。

5-1.包校驗和16位，包括首部和數(shù)據(jù)這兩部分。在計算檢驗和時，要在TCP報文段的前面

加上12字節(jié)的偽首部。

5-2.緊急指針16位，緊急指針指出在本報文段中的緊急數(shù)據(jù)的最后一個字節(jié)的序號。

6-1.可選選項24位，類似IP,是可選選項。

6-2.填充8位，使選項湊足32位。

7-1.用戶數(shù)據(jù)……

TCP如何保證可靠性？(計算機網(wǎng)絡)

1、確認和重傳：接收方收到報文就會確認，發(fā)送方發(fā)送一段時間后沒有收到確認就重傳。

2、數(shù)據(jù)校驗

3、數(shù)據(jù)合理分片和排序：

UDP：IP數(shù)據(jù)報大于1500字節(jié)，大于MTU.這個時候發(fā)送方IP層就需要分片

(fragmentation).把數(shù)據(jù)報分成若干片，使每一片都小于MTU.而接收方IP層則需要進行數(shù)據(jù)報

的重組.這樣就會多做許多事情,而更嚴重的是，由于UDP的特性，當某一片數(shù)據(jù)傳送中丟失時,

接收方便無法重組數(shù)據(jù)報.將導致丟棄整個UDP數(shù)據(jù)報.

tcp會按MTU合理分片，接收方會緩存未按序到達的數(shù)據(jù)，重新排序后再交給應用層。

4、流量控制：當接收方來不及處理發(fā)送方的數(shù)據(jù)，能提示發(fā)送方降低發(fā)送的速率，防止包

丟失。

5、擁塞控制：當網(wǎng)絡擁塞時，減少數(shù)據(jù)的發(fā)送。

TCP數(shù)據(jù)校驗（計算機網(wǎng)絡）

TCP校驗和是一個端到端的校驗和，由發(fā)送端計算，然后由接收端驗證。其目的是為了發(fā)

現(xiàn)TCP首部和數(shù)據(jù)在發(fā)送端到接收端之間發(fā)生的任何改動。如果接收方檢測到校驗和有差

錯，則TCP段會被直接丟棄。

TCP校驗和覆蓋TCP首部和TCP數(shù)據(jù)，而IP首部中的校驗和只覆蓋1P的首部，不覆蓋IP

數(shù)據(jù)報中的任何數(shù)據(jù)。

TCP的校驗和是必需的，而UDP的校驗和是可選的。

TCP和UDP計算校驗和時，都要加上一個12字節(jié)的偽首部。

首先，IP、ICMP、UDP和TCP報文頭部都有校驗和字段，大小都是16bit,算法也基本一

樣：

在發(fā)送數(shù)據(jù)時，為了計算數(shù)據(jù)包的校驗和。應該按如下步驟：

（1）把校驗和字段置為0;

（2）把需校驗的數(shù)據(jù)看成以16位為單位的數(shù)字組成，依次進行二進制反碼求和；

（3）把得到的結(jié)果存入校驗和字段中。

在接收數(shù)據(jù)時，計算數(shù)據(jù)包的校驗和相對簡單，按如下步驟：

（1）把首部看成以16位為單位的數(shù)字組成，依次進行二進制反碼求和，包括校驗和字段；

（2）檢查計算出的校驗和的結(jié)果是否為0；

（3）如果等于0,說明被整除，校驗是和正確。否則，校驗和就是錯誤的，協(xié)議棧要拋棄

這個數(shù)據(jù)包。

雖然上面四種報文的校驗和算法一樣，但在作用范圍存在不同：IP校驗和只校驗20字節(jié)的

IP報頭；而ICMP校驗和覆蓋整個報文（ICMP報頭+ICMP數(shù)據(jù)）；UDP和TCP校驗和不

僅覆蓋整個報文，而且還有12字節(jié)的IP偽首部，包括源IP地址（4字節(jié)）、目的IP地址（4

字節(jié)）、協(xié)議（2字節(jié)，第一字節(jié)補0）和TCP/UDP包長（2字節(jié)）。另外UDP、TCP數(shù)據(jù)報的長

度可以為奇數(shù)字節(jié)，所以在計算校驗和時需要在最后增加填充字節(jié)0（注意，填充字節(jié)只是

為了計算校驗和，可以不被傳送）。

這里還要提一點，UDP的校驗和是可選的，當校驗和字段為0時，表明該UDP報文未使用

校驗和，接收方就不需要校驗和檢查了！那如果UDP校驗和的計算結(jié)果是0時怎么辦呢？

書上有這么一句話：“如果校驗和的計算結(jié)果為0,則存入的值為全1（65535）,這在二進

制反碼計算中是等效的?！?/p>

講了這么多，那這個校驗和到底是怎么算的呢？

什么是二進制反碼求和（1的補碼）

對一個無符號的數(shù)，先求其反碼，然后從低位到高位，按位相加，有溢出則向高位進1（跟

一般的二進制加法規(guī)則一樣），若最高位有進位，則向最低位進1。

首先這里的反碼好像跟我們以前學的有符號數(shù)的反碼不一樣（即正數(shù)的反碼是其本身，負數(shù)

的反碼是在其原碼的基礎(chǔ)上，符號位不變，其余各位取反)，這里不分正負數(shù)，直接每個位

都取反！

上面加粗的那句是跟我們一般的加法規(guī)則不太一樣的地方：最高位有進位，則向最低位進1。

確實有些疑惑，為什么要這樣做呢？仔細分析一下(為了方便說明，以4bit二進制反碼求

和舉例)，上面的這種操作，使得在發(fā)生加法進位溢出時，溢出的值并不是10000,而是1111。

也即是當相加結(jié)果滿1111時溢出，這樣也可以說明為什么0000和1111都表示0了(你同

樣可以發(fā)現(xiàn)，任何數(shù)與這兩個數(shù)做二進制反碼求和運算結(jié)果都是原數(shù)，這恰好符合數(shù)。的加

法意義)。

下面再舉例兩種二進制反碼求和的運算：

原碼加法運算反碼加法運算

3(0011)+5(0101)=8(1000)3(1100)+5(1010)=8(0111)

8(1000)+9(1001)=1(0001)8(0111)+9(0110)=2(1101)

從上面兩個例子可以看出，當加法未發(fā)生溢出時，原碼與反碼加法運算結(jié)果一樣；當有溢出

時，結(jié)果就不一樣了，原碼是滿10000溢出，而反碼是滿1111溢出，所以相差正好是1。

舉例只是為了形象地觀察二進制反碼求和的運算規(guī)則，至于為什么要定義這樣的規(guī)則以及該

運算規(guī)則還存在其它什么特性，可能就需要涉及代數(shù)理論的東西的了。

另外關(guān)于二進制反碼求和運算需要說明的一點是，先取反后相加與先相加后取反，得到的結(jié)

果是一樣的！(事實上我們的編程算法里，幾乎都是先相加后取反。)

1的補碼(相加和補取)猜測是計算機相關(guān)語言.請參考這兩段文字：Itisthel'scomplement

ofthel'scomplementsumofallthe16-bitwordsintheTCPheaderanddata.這是關(guān)于TCP頭

部校驗和字段(checksumfield)的說明.句中的complement意思為“補碼”.對于學習計算機科

學的人來說，補碼不算什么新鮮，現(xiàn)在新鮮的是這篇英語文章出現(xiàn)的是“l(fā)'scomplement”,翻譯

出來應該是“1的補碼”,對于這個筆者以前也沒有碰到過,到網(wǎng)上查吧!網(wǎng)上查詢的結(jié)果,"l's

complement”關(guān)鍵字出現(xiàn)的不少，但都是英文關(guān)鍵字，沒有對應的中文翻譯與解釋，所以先看英

語的,最后自己做解釋吧.補碼：補碼是計算機中二進制數(shù)表達負數(shù)的辦法，這樣可以在計算

機中把兩個數(shù)的減法變成加法.補碼形式有1的補碼和2的補碼，其中1的補碼用在IP、TCP

的校驗和中；平時學生在計算機科學中學習的補碼是2的補碼(即正數(shù)的補碼和原碼相同，

負數(shù)補碼按原碼相應的正數(shù)按位取反再加1).只是平時中文教材及中文翻譯的書中,對此并

不多加解釋,一律翻譯作補碼.比如《ComputerNetwork》(AndrewS.Tanenbaum)在中國的翻

譯版《計算機網(wǎng)絡》(清華大學出版社)對于TCP頭部的校驗和是這樣翻譯的：(原文)

Thechecksumalgorithmissimplytoaddupallthe16-bitwordsinone'scomplementandthento

taketheone'scomplementofthesum.(譯文)校驗和的算法是簡單地將所有16位字以補碼

形式相加,然后再對相加和取補.仔細對比一下本文最上部筆者所碰到的句子,和剛才這個句

子意思是一樣的.這個沒有注明是1的補碼，翻譯時只是以“補碼”說明，也許譯者并不想在這里

多費口舌，因為說明1的補碼實在是一個比較麻煩的事情，筆者在這里翻譯時還是把“1的補

碼”給翻譯出來了，以讓大家注意這個1的補碼并不是平常學的那個2的補碼.筆者只是在此

討論翻譯，不是在討論補碼.1的補碼較復雜，如果有興趣，可以上網(wǎng)查找RFC1071,這是TCP

校驗和權(quán)威的官方說明.

若有客戶打不開網(wǎng)站，分析原因排錯(計算機網(wǎng)絡)

OSI參考模型的基礎(chǔ)知識:

1、OSI模型每一層都為上一層提供服務

2、網(wǎng)絡出現(xiàn)故障從底層往高層一項項的逐步檢查

(1)物理層

物理層故障：查看連接狀態(tài)，查看發(fā)送和接收的數(shù)據(jù)包的具體情況(網(wǎng)線沒有接上(斷

開)、網(wǎng)線的水晶頭該重新置換，沒有接觸良好)

(2)數(shù)據(jù)鏈路層

MAC地址沖突、ADSL撥號上網(wǎng)欠費、網(wǎng)速沒有辦法協(xié)商一致、計算機連接到錯誤的

VLAN

(3)網(wǎng)絡層

配置錯誤IP地址，子網(wǎng)掩碼/配置錯誤的網(wǎng)關(guān)，路由器沒有配置，到達不了目標網(wǎng)絡的

路由器

(4)應用層

應用程序配置錯誤

TCP的擁塞控制(計算機網(wǎng)絡)

TCP/IP協(xié)議族之運輸層協(xié)議(UDP,TCP)

在某段時間內(nèi)，若對網(wǎng)絡中某一資源的需求超過了該資源所能提供的可用部分，網(wǎng)絡的

性能就要變壞，這種情況就叫做擁塞。

從大的方面來看，擁塞控制可分為開環(huán)控制和閉環(huán)控制兩種方法。開環(huán)控制方法就是在

設(shè)計網(wǎng)絡時事先將有關(guān)發(fā)生擁塞的因素考慮周到，力求網(wǎng)絡在工作時不產(chǎn)生擁塞。但一旦整

個系統(tǒng)運行起來，就不再中途進行改正了。閉環(huán)控制是基于反饋環(huán)路的概念。屬于閉環(huán)控制

的有以下幾種措施：

(1)監(jiān)測網(wǎng)絡系統(tǒng)以便檢測到擁塞在何時、何處發(fā)生。

(2)把擁塞發(fā)生的信息發(fā)送到可采取行動的地方。

(3)調(diào)整網(wǎng)絡系統(tǒng)的運行以解決出現(xiàn)的問題。

擁塞控制與流量控制

擁塞控制就是防止過多的數(shù)據(jù)注入到網(wǎng)絡中，這樣可以使網(wǎng)絡中的路由器或鏈路不致

過載。擁塞控制所要做的都有一個前提，就是網(wǎng)絡能夠承受現(xiàn)有的網(wǎng)絡負荷。擁塞控制是

一個全局性的過程，涉及到所有的主機、所有的路由器，以及與降低網(wǎng)絡傳輸性能有關(guān)的所

有因素。

流量控制往往指點對點通信量的控制，是個端到端的問題(接收端控制發(fā)送端)。流

量控制所要做的就是抑制發(fā)送端發(fā)送數(shù)據(jù)的速率，以便使接收端來得及接收。

二者被弄混的原因是，因為某些擁塞控制算法是向發(fā)送端發(fā)送控制報文，并告訴發(fā)送端,

網(wǎng)絡已出現(xiàn)麻煩，必須放慢發(fā)送速率。這點和流量控制相似。

擁塞控制的方法

因特網(wǎng)建議標準RFC2581定義了進行擁塞控制的四種算法，即慢開始(Slow-start),擁

塞避免(CongestionAvoidance),快重傳(FaslRestrangsmit)和快恢復(FastRecovery)。我

們假定

1)數(shù)據(jù)是單方向傳送，而另外一個方向只傳送確認。

2)接收方總是有足夠大的緩存空間，因為發(fā)送窗口的大小由網(wǎng)絡的擁塞程度來決定。

下圖是慢啟動和擁塞避免的一個可視化描述。我們以段為單位來顯示cwnd和ssthresh,

但它們實際上都是以字節(jié)為單位進行維護的。

cwud

（報文段）

往返時間

擁塞窗口概念：發(fā)送報文段速率的確定，既要根據(jù)接收端的接收能力，又要從全局

考慮不要使網(wǎng)絡發(fā)生擁塞，這由接收窗口和擁塞窗口兩個狀態(tài)量確定。接收端窗口（Reciver

Window）又稱通知窗口（AdvertisedWindow）,是接收端根據(jù)目前的接收緩存大小所許諾的最

新窗口值，是來自接收端的流量控制。擁塞窗口cwnd（CongestionWindow）是發(fā)送端根據(jù)自

己估計的網(wǎng)絡擁塞程度而設(shè)置的窗口值，是來自發(fā)送端的流量控制。

（1）慢啟動原理

1）當主機開始發(fā)送數(shù)據(jù)時，如果立即將較大的發(fā)送窗口的全部數(shù)據(jù)字節(jié)都注入到網(wǎng)

絡中，那么由于不清楚網(wǎng)絡的情況，有可能引起網(wǎng)絡擁塞

2）比較好的方法是試探一下，即從小到達逐漸增大發(fā)送端的擁塞控制窗口數(shù)值

3）通常在剛剛開始發(fā)送報文段時可先將擁塞窗口cwnd（擁塞窗口）設(shè)置為一個最大

報文段的MSS的數(shù)值。在每收到一個對新報文段確認后，將擁塞窗口增加至多一個MSS

的數(shù)值，當rwind（接收窗口）足夠大的時候，為了防止擁塞窗口cwind的增長引起網(wǎng)絡擁

塞，還需要另外一個變量---慢開始門限ssthresh

（2）擁塞控制

具體過程為：

1）TCP連接初始化，將擁塞窗口設(shè)置為1

2）執(zhí)行慢開始算法：cwind按指數(shù)規(guī)律增長，直到cwind==sslhress開始執(zhí)行擁

塞避免算法：cwnd按線性規(guī)律增長

3）當網(wǎng)絡發(fā)生擁塞，把ssthresh值更新為擁塞前ssthresh值的一半，cwnd重新設(shè)

置為1,按照步驟（2）執(zhí)行。

輪次I

輪次2

輪次3

圖5-24發(fā)送方每收到一個確認就把窗口cwnd加1

（3）快重傳和快恢復

一條TCP連接有時會因等待重傳計時器的超時而空閑較長的時間，慢開始和擁塞避

免無法很好的解決這類問題，因此提出了快重傳和快恢復的擁塞控制方法.

快重傳算法并非取消了重傳機制，它要求接收方每收到一個失序的報文段后就立即

發(fā)出重復確認，如果當發(fā)送端接收到三個重復的確認ACK時，則斷定分組丟失，立即重傳

丟失的報文段，而不必等待重傳計時器超時。

例如：Ml,M2,M3--->Ml,M3,缺失M2,則接收方向發(fā)送方持續(xù)發(fā)送M2重復

確認，當發(fā)送方收到M2的三次重復確認，則認為M2報文丟失，啟動快重傳機制，重傳數(shù)

據(jù)，其他數(shù)據(jù)發(fā)送數(shù)據(jù)放入隊列，待快重傳結(jié)束后再正常傳輸。

快恢復算法有以下兩個要點：

1）當發(fā)送方連續(xù)收到接收方發(fā)來的三個重復確認時，就執(zhí)行“乘法減小”算法，把慢

開始門限減半（ssthresh=ssthresh/2）,這是為了預防網(wǎng)絡發(fā)生擁塞。

2）由于發(fā)送方現(xiàn)在認為網(wǎng)絡很可能沒有發(fā)生擁塞，因此現(xiàn)在不執(zhí)行慢開始算法，

而是把cwnd（擁塞窗口）值設(shè)置為慢開始門限減半后的值（cwnd=ssthresh/2）,然后開始執(zhí)行

擁塞避免算法，使擁塞窗口緩慢地線性增大。

OSI七層協(xié)議分別是什么，每一層功能（計算機網(wǎng)絡）★★

OSI模型，即開放式通信系統(tǒng)互聯(lián)參考模型（OpenSystemInterconnectionReference

Model）,是國際標準化組織提出的一個試圖使各種計算機在世界范圍內(nèi)互連為網(wǎng)絡的

標準框架，簡稱OSI。

OSI分層（7層）：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層、應用層

TCP/IP分層（4層）：網(wǎng)絡接口層、網(wǎng)際層、傳輸層、應用層

五層協(xié)議：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、應用層

每層的作用及協(xié)議：

物理層：通過媒介傳輸比特，確定機械及電氣規(guī)范。RJ45,CLOCK,IEEE802.3（中繼器、

集線器）

數(shù)據(jù)鏈路層：將比特組裝成幀和點到點的傳遞幀。PPP,FR,VLAN,MAC（網(wǎng)橋、交換機）

網(wǎng)絡層：負責數(shù)據(jù)包從源到目的端的傳遞和網(wǎng)際互聯(lián)（包packet），路由尋址。

IP,ICMP,ARP,RARP,OSPF,IPX,RIP,IGRP（路由器）

傳輸層：提供端到端的可靠報文傳遞和錯誤恢復（段Segment）。TCP,UDP

會話層：建立、管理和終止會話（會話協(xié)議數(shù)據(jù)單元SPDU）。NFS,SQL,NETBIOS,RPC

表示層：刻數(shù)據(jù)進行翻譯、加密和壓縮（表示協(xié)議數(shù)據(jù)單元PPDU）。JPEG,MPEG

應用層：允許訪問OSI環(huán)境的手段（應用協(xié)議數(shù)據(jù)單元APDU）。

FTP,DNS,Telnet,SMTP,HTTP,WWW,NFS

httpl.O與http2的區(qū)別（計算機網(wǎng)絡）

HTTP1.0

HTTP協(xié)議老的標準是HTTP/1.0,為了提高系統(tǒng)的效率，HTTP1.0規(guī)定瀏覽器與服務器只

保持短暫的連接，瀏覽器的每次請求都需要與服務器建立一個TCP連接，服務器完成請求

處理后立即斷開TCP連接，服務器不跟蹤每個客戶也不記錄過去的請求。但是，這也造成

了一些性能上的缺陷，例如，一個包含有許多圖像的網(wǎng)頁文件中并沒有包含真正的圖像數(shù)據(jù)

內(nèi)容，而只是指明了這些圖像的URL地址，當WEB瀏覽器訪問這個網(wǎng)頁文件時，瀏覽器

首先要發(fā)出針對該網(wǎng)頁文件的請求，當瀏覽器解析WEB服務器返回的該網(wǎng)頁文檔中的

HTML內(nèi)容時，發(fā)現(xiàn)其中的圖像標簽后，瀏覽器將根據(jù)標簽中的src屬性所指定的URL地

址再次向服務器發(fā)出下載圖像數(shù)據(jù)的請求。顯然，訪問一個包含有許多圖像的網(wǎng)頁文件的整

個過程包含了多次請求和響應，每次請