TCP/IP經典問題總結

一、A進程經過TCP向另外一臺機器上的B進程發送了一個字符串「hello」，TCP返回對方成功接收的確認信息，請問，如今進程A是否能夠確定地說進程B收到了它發送的字符串？

答案：不能！舉反例，進程B所在機器的TCP收到進程A發送的「hello」信息後，告訴進程A發送成功，但有可能沒有當即將數據交給進程B，而是放在本身的緩衝區中，等待進程B讀取，若是機器此時忽然掉電，緩衝區中的信息將丟失，進程B將不可能收到「hello」字符串。

二、有什麼辦法來儘可能避免上述狀況的發生呢？

答案：將TCP報文段首部中的PSH標誌置1，這樣會讓B端的TCP協議收到數據後儘快交給進程B，能不緩存儘可能不要緩存。

三、咱們知道一般TCP鏈接的創建須要3次握手，關閉須要4次握手，爲何關閉會多一次呢？

答案：簡單說，就是TCP容許半關閉狀態的存在。當進程A向進程B發送FIN，B也向A發送確認後。此時此刻的狀態就是半關閉狀態，A發送的FIN就是告訴B：「我要發送的數據都發送完了」但B沒有發送FIN給A，有可能表明B還有沒發送完的數據，若是B也發送完數據了，B就發送FIN給進程A，進程A確認B發送的FIN，這時，雙方都已經發送完了數據，鏈接就斷開了，TCP回收相關資源。

四、假如服務器忽然掉電重啓，但客戶端並不知情，請問此時兩者之間的TCP鏈接處於什麼狀態？

答案：處於半打開狀態。就是客戶端還以爲鏈接是正常的，服務器這邊已經沒有鏈接的任何信息了。

五、那麼，假如此時客戶端經過這個鏈接向服務器請求數據，服務器會怎麼應對呢？

答案：服務器收到客戶端的請求會進行一次ARP查詢，得到客戶端MAC地址，然而因爲已經丟失了全部鏈接信息，此時的服務器是一臉懵逼（就像喝了孟婆湯！），因而乎，它會發一個RST給客戶端，表示：「哥們，我不認識你，想跟我說話請先發送SYN！」

六、假如客戶端按照服務器的要求從新創建鏈接，卻搞錯了服務器的端口號，會發生什麼狀況呢？

答案：有兩種可能，一種是服務器端的TCP收到客戶端請求，查看本機上是否有進程在監聽相應的端口，若是有，就把請求交給這個進程，通常而言，這個進程不會接受這個鏈接的，因而它會發一個RST給客戶端。還有一種多是TCP沒有找到哪一個進程在監聽相應的端口，因而TCP就會直接發一個RST給客戶端，通常而言都會是這種狀況。

七、假如如今有一個多進程服務器，服務器進程爲A,接受一個鏈接後新建一個進程B來處理鏈接，再接受一個鏈接後又建一個進程C來處理這個鏈接，請問，進程ABC是否監聽一樣的端口？

答案：是！

八、那TCP接收到發送給這個端口的報文段，怎麼決定發給哪一個進程呢？

答案：首先，全部的SYN報文段都會發送給服務器進程A，其餘的報文段依據<sourceIP:port,targetIP:port>這個四元組來決定發送給進程B仍是進程C。

九、假如上面的服務器進程A收到一個鏈接請求，正在爲這個請求建立處理進程的時候，又有新的鏈接請求進來了，TCP會怎麼處理呢？

答案：通常狀況下，服務器進程A會給TCP一個指示，讓TCP維護一個適當長度的鏈接隊列，TCP與新鏈接請求完成三次握手後，就會把這個鏈接放入鏈接隊列中，服務器進程A會在合適的時候來從這個隊列中取鏈接。

十、這個鏈接對列是否會對服務器的併發處理能力產生影響呢？若是會，會有什麼影響？

答案：不會！兩者沒有必然關係。

十一、MSS和MTU各是什麼，兩者是什麼關係？

答案：MSS是TCP最大報文段長度，就是TCP發送數據須要對數據分段時，最大的段的字節數。MTU是最大傳輸單元，一般由網卡的硬件特性規定，表示經過該網卡傳輸的數據單元最大的字節數。MSS要受同一臺機器上的MTU限制。好比MTU爲1500字節，那麼MSS就只能是1460字節，這是由於1460字節的數據在經過網卡向外傳輸時，會加上20字節的ip頭和20字節的tcp頭。

十二、假設機器A和B的MSS分別是1400和1600，請問，A經過TCP向B發送數據時，是否能夠發送長度爲1600字節的數據段？

答案：不能夠，雖然發送1600字節的數據段沒有突破B的MSS，可是突破了A本身的MSS。這樣一來，當這1600字節的數據段經過A的網卡向B發送時，會被切分爲2個IP片，每一個爲840字節，以保證不突破A的MTU，這顯然下降了傳輸的效率，由於兩個840字節中有着相同的IP頭和TCP頭。

1三、機器A和B有一條TCP鏈接，假如A想盡快斷開鏈接，應當怎麼辦？

答案：A能夠直接給B發送一個RST，就能夠了，至關於告訴B，我關閉鏈接了，你看着辦吧。這叫作異常關閉。

1四、B的TCP收到A發來的RST，會怎麼辦？

答案：B的TCP會告訴上層的進程，鏈接已經斷開了，而後就會回收這條鏈接的資源，並不會發送任何確認信息給A。所謂你無情休怪我不義。

1五、假設A正常斷開與B的TCP鏈接，當收到B的FIN時，A發送ACK給B，是否就算完成了4次握手，鏈接已經成功斷開？

答案：不是，A的TCP會啓動一個定時器，等待2MSL的時間，這主要是爲了防止A的ACK沒有成功傳到B，讓B覺得本身的FIN沒有送到A處，反覆重傳FIN的問題。2MSL的時間到時，若是A沒有再次收到B的FIN，說明B成功收到A的ACK，A就能夠安全地斷開這個鏈接，若期間再次收到B的FIN，則A會重傳ACK。