校招面試必考的TCP
本文公眾號(hào)來源：美碼師
作者：美碼師
我們在平時(shí)的開發(fā)中，或多或少都會(huì)涉獵到網(wǎng)絡(luò)傳輸這塊。
?這篇文章，主要是整理一下 TCP 的一些知識(shí)要點(diǎn)，作為一名開發(fā)者來說，盡管有那么多的基礎(chǔ)設(shè)施(框架、組件)幫我們屏蔽了這些細(xì)節(jié)。當(dāng)我仍然認(rèn)為了解它的一些基本原理必有些裨益，尤其是當(dāng)你在分布式環(huán)境上遇到一些棘手問題時(shí)，一些原理性的知識(shí)可能會(huì)讓你快速找到答案。
一、起源
TCP 是傳輸層的協(xié)議，全稱是叫做 Transmission Control Protocol，這個(gè)協(xié)議在 IETF RFC 793 進(jìn)行了定義。在互聯(lián)網(wǎng)產(chǎn)生之前，我們的電腦都是相互獨(dú)立的，每臺(tái)機(jī)器都有著自己的操作系統(tǒng)并保持著自己的運(yùn)行。于是，為了將這些電腦連接起來，并能夠基于一種"通道"的形式進(jìn)行數(shù)據(jù)、資源的傳輸及交互，IETF 制定了 TCP 協(xié)議。
那么，IETF又是什么？這是一個(gè)令人尊敬的技術(shù)組織，叫 Internet Engineering Task Force，即互聯(lián)網(wǎng)工程任務(wù)組。這是一個(gè)成立于1985年的開放性組織，現(xiàn)在我們所提到的 HTTP、TCP、IP 這些重要的網(wǎng)絡(luò)協(xié)議，都是出自于該組織。可以這么說，IETF 是互聯(lián)網(wǎng)的始作俑者，沒有它就沒有現(xiàn)在繁榮的互聯(lián)網(wǎng)了。
值得一提的是，IETF并非權(quán)貴組織，它是一個(gè)"來自民間" 的自組織、自管理的團(tuán)隊(duì)，非常崇尚于自由平等的精神。
整個(gè)互聯(lián)網(wǎng)的底層機(jī)制是由一套標(biāo)準(zhǔn)網(wǎng)絡(luò)協(xié)議組成的，為了更方便于理解，人們便定義了所謂的“網(wǎng)絡(luò)分層模型"。在學(xué)習(xí)計(jì)算機(jī)網(wǎng)絡(luò)課程的時(shí)候，都會(huì)提到兩種網(wǎng)絡(luò)模型，如下：
OSI 模型，全稱為 Open System Interconnection
即開放系統(tǒng)互聯(lián)模型，這個(gè)是由 ISO(International Organization for Standardization) 國際標(biāo)準(zhǔn)化組織提出的。它主要是用來解決當(dāng)時(shí)各個(gè)網(wǎng)絡(luò)技術(shù)供應(yīng)商在協(xié)議上無法統(tǒng)一的問題，通過將整個(gè)網(wǎng)絡(luò)體系結(jié)構(gòu)抽象為 7層，從最底層的物理層、數(shù)據(jù)鏈路層一直到最上面的應(yīng)用層都做了定義。
在以前，由于術(shù)語眾多，有許多人經(jīng)常被OSI、ISO所迷惑..
TCP/IP，即 TCP/IP Protocol Suite(協(xié)議套件)是一個(gè)以TCP協(xié)議和IP協(xié)議為核心的通信模型，該模型采用協(xié)議堆棧的方式來實(shí)現(xiàn)許多通信協(xié)議，并將通訊體系抽象為4層。TCP/IP 模型最早發(fā)源于美國國防部（縮寫為DoD）的ARPA網(wǎng)項(xiàng)目，此后就交由IETF組織來維護(hù)。
從上面的圖中可以看出，TCP/IP 基本上是OSI 模型的簡化版，當(dāng)然也更加容易理解。
在網(wǎng)絡(luò)層以下，物理層、數(shù)據(jù)鏈路層所涉及的一些技術(shù)手段及概念都相對(duì)晦澀難懂，就比如光纜、中繼器、交換機(jī)等需要一些專業(yè)背景才能掌握通透。對(duì)于大多數(shù)的軟件應(yīng)用來說，將網(wǎng)絡(luò)層以下的部分統(tǒng)稱為“網(wǎng)絡(luò)接口層" 無疑是更加簡單的。
因此，OSI 模型盡管非常完善且全面，但已經(jīng)被 TCP/IP 模型所淘汰，在互聯(lián)網(wǎng)應(yīng)用盛行的今天很少被提及。
圖-TCP/IP 網(wǎng)絡(luò)模型
二、TCP 協(xié)議
TCP 是整個(gè) TCP/IP 協(xié)議族中最重要的傳輸層協(xié)議，它定義了一種面向連接的、可靠的、基于流的傳輸方式。HTTP 是基于 TCP 的，所以說 TCP 是整個(gè)互聯(lián)網(wǎng)的協(xié)議其一并不為過。同時(shí)，我們在使用 HTTP 協(xié)議實(shí)現(xiàn)應(yīng)用系統(tǒng)間的交互時(shí)，也經(jīng)常免不了會(huì)與 TCP 打上交道。因此有必要了解一些基本機(jī)制。
TCP 的特點(diǎn)？
首先，TCP 是基于連接的，也就是在進(jìn)行數(shù)據(jù)傳輸之前，客戶端與服務(wù)端(或者說是通信的雙方)需要先建立一個(gè)可信的連接。在數(shù)據(jù)傳輸結(jié)束后，再通過一種協(xié)定的方式斷開連接，由通信的雙方釋放資源。這里涉及到的，就是常說的"三次握手"、"四次揮手"
其次，TCP 是可靠的，它定義了一種數(shù)據(jù)包的"超時(shí)重傳機(jī)制"，簡單說，就是每一個(gè)數(shù)據(jù)包在發(fā)送出去后的都會(huì)等待一個(gè)響應(yīng)。如果指定時(shí)間內(nèi)沒有收到響應(yīng)，由發(fā)送方進(jìn)行一定次數(shù)的重傳來保證數(shù)據(jù)的可靠傳輸。
最后，TCP 是基于流的，這是指在傳輸數(shù)據(jù)時(shí)應(yīng)用層不需要關(guān)注數(shù)據(jù)包的邊界，TCP在數(shù)據(jù)傳輸時(shí)會(huì)自動(dòng)根據(jù)網(wǎng)絡(luò)環(huán)境將數(shù)據(jù)進(jìn)行緩沖、分組、合并。這點(diǎn)跟基于報(bào)文的協(xié)議(UDP)是截然不同的。當(dāng)然，基于流的傳輸也保證了數(shù)據(jù)收發(fā)的有序性，因此每個(gè)數(shù)據(jù)包都附帶上一個(gè)屬于當(dāng)前連接的序列號(hào)。
怎么理解全雙工？
全雙工是通訊上的術(shù)語，一般在軟件開發(fā)領(lǐng)域提到的并不多。這是指數(shù)據(jù)同時(shí)在兩個(gè)方向上傳輸，TCP 是基于全雙工的可信傳輸協(xié)議。當(dāng)然 UDP 也可以實(shí)現(xiàn)全雙工的傳輸，但 TCP 只能實(shí)現(xiàn)點(diǎn)對(duì)點(diǎn)的傳輸，無法支持廣播或者多播(分組)
黑板：半雙工的區(qū)別在于，同一時(shí)間只能有一個(gè)方向的傳輸
TCP 的數(shù)據(jù)包如何組織？
透視一個(gè)協(xié)議的最原始的方法就是看它的數(shù)據(jù)包，一個(gè)TCP 的報(bào)文格式如下：
這里面的字段就包括了：
源端口?表明發(fā)送端所使用的端口號(hào)，用于目標(biāo)主機(jī)回應(yīng)。
目的端口?表明要連接的目標(biāo)主機(jī)的端口號(hào)。
序號(hào)?表明發(fā)送的數(shù)據(jù)包的順序，一般為上次發(fā)送包中的順序號(hào)+1。若該數(shù)據(jù)包是整個(gè)TCP連接中的第一個(gè)包(SYN包)，則該值是隨機(jī)生成的。
確認(rèn)號(hào)?表明本端TCP已經(jīng)接收到的數(shù)據(jù)，其值表示期待對(duì)端發(fā)送的下一個(gè)字節(jié)的序號(hào)。實(shí)際上告訴對(duì)方，在這個(gè)序號(hào)減1以前的字節(jié)已正確接收。若該數(shù)據(jù)包是整個(gè)TCP連接中的第一個(gè)包(SYN包)，則確認(rèn)號(hào)一般為0。
數(shù)據(jù)偏移?表示以32位(4字節(jié))為單位的TCP分組頭的總長度(首部長度)，用于確定用戶數(shù)據(jù)區(qū)的起始位置。在沒有可變內(nèi)容的情況下，TCP頭部的大小為20字節(jié)，對(duì)應(yīng)該值為5。
標(biāo)志位?緊急標(biāo)志位(URG)：開啟時(shí)表明此數(shù)據(jù)包處于緊急狀態(tài)應(yīng)該優(yōu)先處理 確認(rèn)標(biāo)志位(ACK)：開啟時(shí)表明確認(rèn)號(hào)有效，否則忽略確認(rèn)號(hào) 推送標(biāo)志位(PSH)：開啟時(shí)表明應(yīng)該盡快交付給應(yīng)用進(jìn)程，而不必等到緩存區(qū)填滿才推送，比如 telnet 的場景 復(fù)位標(biāo)志位(RST)：開啟時(shí)表明TCP連接出現(xiàn)連接出現(xiàn)錯(cuò)誤，數(shù)據(jù)包非法拒絕連接 同步標(biāo)志位(SYN)：開啟時(shí)表明連接建立的標(biāo)志 終止標(biāo)志位(FIN)：開啟時(shí)表明釋放一個(gè)連接
窗口大小?表明期望接受到的數(shù)據(jù)包字節(jié)數(shù)，用于擁塞控制。
校驗(yàn)和?實(shí)現(xiàn)對(duì)TCP報(bào)文頭以及數(shù)據(jù)區(qū)進(jìn)行校驗(yàn)。
緊急指針?在緊急狀態(tài)下(URG打開)，指出窗口中緊急數(shù)據(jù)的位置(末端)。
選項(xiàng)(可變)?用于支持一些特殊的變量，比如最大分組長度(MSS)。
填充?用于保證可變選項(xiàng)為32 bit的整數(shù)倍。
黑板：一般情況下TCP 頭部為20字節(jié)，加上20字節(jié)的 IP頭部，一個(gè)數(shù)據(jù)包至少包含40字節(jié)的頭部
三、TCP 工作流程
鏈?zhǔn)侵告溌?/span>，這個(gè)是物理層的概念，比如光纜光纖，或是無線的電磁波。但這里所說的鏈路其實(shí)是網(wǎng)絡(luò)連接的意思，即 IP 上層的概念。
那么，一個(gè)TCP 正常的通訊流程，會(huì)包含建鏈(建立連接)、傳輸數(shù)據(jù)、拆鏈(關(guān)閉連接)，
如下圖所示：
(圖來自網(wǎng)絡(luò))
據(jù)上圖所示，在進(jìn)行 TCP 進(jìn)行數(shù)據(jù)傳輸時(shí)，都不可避免的會(huì)經(jīng)過這兩個(gè)階段：
三次握手建立連接
執(zhí)行數(shù)據(jù)傳輸、雙方讀寫
四次揮手釋放連接
下面，重點(diǎn)說明下建鏈與拆鏈的過程
四、 三次握手
在建立TCP連接時(shí)，需要經(jīng)過三次交互，也成為三次握手(HandShake)。
1、客戶端發(fā)起連接請(qǐng)求，發(fā)送 SYN包（SYN=i）到服務(wù)器，并進(jìn)入到SYN-SEND狀態(tài)，等待服務(wù)器確認(rèn) 2、服務(wù)器收到SYN包后，必須確認(rèn)客戶的 SYN（ack=i+1），同時(shí)自己也發(fā)送一個(gè)SYN包（SYN=k），即SYN+ACK包，此時(shí)服務(wù)器進(jìn)入SYN-RECV狀態(tài) 3、客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)報(bào)ACK（ack=k+1），此后客戶端和服務(wù)器進(jìn)入ESTABLISHED狀態(tài)，雙方可以開始傳送數(shù)據(jù)。
在談?wù)撊挝帐值臅r(shí)候，有幾個(gè)問題是需要關(guān)注的：
問題1. 為什么是三次握手
這個(gè)問題在技術(shù)面試時(shí)屢試不爽，原話是能不能兩次，或者是四次握手呢？答案就是，TCP 是可靠的傳輸，在建立連接時(shí)就應(yīng)該經(jīng)過兩端的確認(rèn)過程，如上面的流程， 只有在三次握手的情況下，客戶端和服務(wù)端都經(jīng)過了一次真正(SYN+ACK)的確認(rèn)過程。這樣的連接便認(rèn)為是可信的。此外，如果僅僅只是兩次握手，一旦網(wǎng)絡(luò)不穩(wěn)定造成 SYN 包重傳則會(huì)直接導(dǎo)致重復(fù)建立連接，浪費(fèi)資源。
問題2. 什么是syn flood攻擊
syn flood 是一種經(jīng)典的 ddos攻擊手段，這里面用到了TCP 三次握手存在的漏洞。在上面的圖中，可以看到當(dāng)服務(wù)端接收到 SYN 后進(jìn)入 SYN-RECV 狀態(tài)，此時(shí)的連接稱為半連接，同時(shí)會(huì)被服務(wù)端寫入一個(gè) 半連接隊(duì)列。想象一下，如果攻擊者在短時(shí)間內(nèi)不斷的向服務(wù)端發(fā)送大量的 SYN 包而不響應(yīng)，那么服務(wù)器的 半連接隊(duì)列很快會(huì)被寫滿，從而導(dǎo)致無法工作。實(shí)現(xiàn) syn flood 的手段，可以通過偽造源 IP 的方式，這樣服務(wù)器的響應(yīng)就永遠(yuǎn)到達(dá)不了客戶端(握手無法完成)；當(dāng)然，通過設(shè)定客戶端防火墻規(guī)則也可以達(dá)到同樣的目的。
對(duì) syn flood 實(shí)現(xiàn)攔截是比較困難的，可以通過啟用 syn_cookies 的方式實(shí)現(xiàn)緩解，但這通常不是最佳方案。最好的辦法是通過專業(yè)的防火墻來解決，基本上所有的云計(jì)算大T 都具備這個(gè)能力。關(guān)于 syn flood 可以看看這篇文章
問題3. 半連接隊(duì)列和全連接隊(duì)列如何調(diào)優(yōu)
這里提到了一個(gè)"半連接隊(duì)列"(syns queue)，與其對(duì)應(yīng)的還有一個(gè) "全連接隊(duì)列"(accept queue) 前者用于暫存未建立完全的連接，后者是連接在成功建立后進(jìn)入的一個(gè)隊(duì)列。半連接隊(duì)列默認(rèn)大小可以通過內(nèi)核參數(shù)調(diào)整：
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
黑板：tcpmaxsynbacklog 在 syncookies 開啟時(shí)是無效的，這兩個(gè)選項(xiàng)存在沖突
對(duì)于全連接隊(duì)列，如果服務(wù)器未能及時(shí)通過 accept 調(diào)用將其中的連接取走，會(huì)導(dǎo)致隊(duì)列溢出(連接失效)
全連接隊(duì)列的大小的內(nèi)核調(diào)優(yōu)方式：
echo 4096 > /proc/sys/net/core/somaxconn
那么，是不是只有內(nèi)核調(diào)優(yōu)這種方法能影響這兩個(gè)參數(shù)呢？答案是否定的。實(shí)際上，在應(yīng)用層調(diào)用 socket listen 時(shí)也支持設(shè)置一個(gè) backlog參數(shù)，這幾個(gè)之間的關(guān)系如下：
半連接隊(duì)列長度 = min(backlog，內(nèi)核 net.core.somaxconn，內(nèi)核 tcp_max_syn_backlog)全連接隊(duì)列長度 = min(backlog，內(nèi)核 net.core.somaxconn)
黑板：一般的應(yīng)用服務(wù)器如 netty、tomcat 都支持設(shè)置 backlog 參數(shù)，但是在真正進(jìn)行調(diào)優(yōu)時(shí)還需要配合考慮內(nèi)核參數(shù)的配置。
五、 四次揮手
在釋放連接時(shí)，由于TCP是全雙工的，因此最后要由兩端分別進(jìn)行關(guān)閉，這個(gè)流程如下：
1、客戶端發(fā)送一個(gè)FIN，用來關(guān)閉客戶端到服務(wù)器的數(shù)據(jù)傳送，客戶端進(jìn)入FINWAIT1狀態(tài)。2、服務(wù)器收到FIN后，發(fā)送一個(gè)ACK給客戶端，確認(rèn)序號(hào)為收到序號(hào)+1（與SYN相同，一個(gè)FIN占用一個(gè)序號(hào)），服務(wù)器進(jìn)入CLOSEWAIT狀態(tài)，而客戶端進(jìn)入FINWAIT2狀態(tài)。3、服務(wù)器發(fā)送一個(gè)FIN，用來關(guān)閉服務(wù)器到客戶端的數(shù)據(jù)傳送，服務(wù)器進(jìn)入LASTACK狀態(tài)。4、客戶端收到FIN后，客戶端進(jìn)入TIMEWAIT狀態(tài)，接著發(fā)送一個(gè)ACK給服務(wù)器，確認(rèn)序號(hào)為收到序號(hào)+1，服務(wù)器進(jìn)入CLOSED狀態(tài)，完成釋放。
關(guān)閉連接有主動(dòng)關(guān)閉和被動(dòng)關(guān)閉一說，這里為了簡化理解，我們以客戶端作為主動(dòng)關(guān)閉方，服務(wù)器為被動(dòng)關(guān)閉方。
四次揮手需要關(guān)注的問題：
問題1. 為什么是四次揮手
發(fā)送FIN的一方就是主動(dòng)關(guān)閉(客戶端)，而另一方則為被動(dòng)關(guān)閉(服務(wù)器)。當(dāng)一方發(fā)送了FIN，則表示在這一方不再會(huì)有數(shù)據(jù)的發(fā)送。其中當(dāng)被動(dòng)關(guān)閉方受到對(duì)方的FIN時(shí)，此時(shí)往往可能還有數(shù)據(jù)需要發(fā)送過去，因此無法立即發(fā)送FIN(也就是無法將FIN與ACK合并發(fā)送)， 而是在等待自己的數(shù)據(jù)發(fā)送完畢后再單獨(dú)發(fā)送FIN，因此整個(gè)過程需要四次交互。
問題2. 什么是半關(guān)閉
客戶端在收到第一個(gè)FIN的ACK響應(yīng)后，會(huì)進(jìn)入FINWAIT2 狀態(tài)時(shí)，此時(shí)服務(wù)器處于 CLOSEWAIT狀態(tài)，這種狀態(tài)就稱之為半關(guān)閉。從半關(guān)閉到全關(guān)閉，需要等待第二次FIN的確認(rèn)才算結(jié)束。此時(shí)，客戶端要等到服務(wù)器的FIN才能進(jìn)入TIMEWAIT， 如果對(duì)方遲遲不發(fā)送FIN呢，則會(huì)等待一段時(shí)間后超時(shí)，這個(gè)可以通過內(nèi)核參數(shù)tcpfin_timeout控制，默認(rèn)是60s。
問題3. 為什么服務(wù)器會(huì)有大量 closewait
半關(guān)閉的狀態(tài)下的服務(wù)器連接會(huì)處于 closewait 狀態(tài)，直到服務(wù)器發(fā)送了FIN。那么在應(yīng)用層則是調(diào)用socket.close()會(huì)執(zhí)行FIN的發(fā)送，如果服務(wù)器出現(xiàn)大量CLOSE_WAIT狀態(tài)的連接，那么有可能的原因：
服務(wù)器壓力過大，根本來不及調(diào)用close
存在連接泄露問題(Bug)，服務(wù)器未及時(shí)關(guān)閉連接
問題4. timewait 會(huì)帶來什么問題
當(dāng)客戶端收到了對(duì)方的FIN時(shí)，會(huì)進(jìn)入TIMEWAIT狀態(tài)，此時(shí)會(huì)保持一段時(shí)間再進(jìn)入CLOSE狀態(tài)。這么做的原因主要還是為了可靠的關(guān)閉連接。在將TCP 進(jìn)行可靠性設(shè)計(jì)之時(shí)就考慮了許多網(wǎng)絡(luò)的不穩(wěn)定性的因素，比如：
發(fā)送給對(duì)方的ACK 可能會(huì)無法及時(shí)收到，此時(shí)對(duì)方可能重傳FIN過來，如果提前進(jìn)入CLOSE則會(huì)返回RST而不是ACK，就會(huì)影響關(guān)閉流程。
因此 TIMEWAIT 狀態(tài)默認(rèn)會(huì)持續(xù)一段時(shí)間，直到確認(rèn)不會(huì)再有重傳的數(shù)據(jù)包之后再安全的關(guān)閉。
黑板：這里timewait的持續(xù)時(shí)間默認(rèn)是 2*MSL(總共1分鐘)，這個(gè)MSL叫Max Segment Lifetime，也就是關(guān)于一個(gè)數(shù)據(jù)包在網(wǎng)絡(luò)中傳輸?shù)淖畲笊芷诘念A(yù)設(shè)。MSL默認(rèn)是30s，當(dāng)然這個(gè)值在現(xiàn)在已經(jīng)可以大幅度縮減。可見在當(dāng)時(shí)在設(shè)計(jì)之初，網(wǎng)絡(luò)狀況有多么的糟糕。
那么timewait會(huì)帶來什么問題？如果頻繁的主動(dòng)關(guān)閉連接，可能會(huì)產(chǎn)生大量 timewait，由于timewait 的連接占用了一個(gè)句柄及少量內(nèi)存(4K)，那么就有可能會(huì)影響其他連接的建立，比如：
出現(xiàn) too many open files 異常..
該如何解決：
重用連接，避免頻繁關(guān)閉，比如使用連接池
參數(shù)調(diào)優(yōu)，比如開啟tcptwreuse選項(xiàng)支持timewait連接的重復(fù)使用。
黑板：HTTP 協(xié)議里頭發(fā)現(xiàn)了timewait的問題，于是在 HTTP 1.1 中定義了 KeepAlive 用來支持連接的重用。
問題5. RST 是什么，為什么會(huì)出現(xiàn)
RST 是一個(gè)特殊的標(biāo)記，用來表示當(dāng)前應(yīng)該立即終止連接。以下這些情況都會(huì)產(chǎn)生RST：
向一個(gè)未被監(jiān)聽的端口發(fā)送數(shù)據(jù)
對(duì)方已經(jīng)調(diào)用 close 關(guān)閉連接
存在一些數(shù)據(jù)未處理(接收緩沖區(qū))，請(qǐng)求關(guān)閉連接時(shí)，會(huì)發(fā)送RST強(qiáng)制關(guān)閉
某些請(qǐng)求發(fā)生了超時(shí)
RST 機(jī)制有時(shí)候也會(huì)被利用，做一些端口的掃描，如下：
-> 端口開啟，可接受SYN
-> 端口關(guān)閉，響應(yīng)RST
小結(jié)
原文只是想總結(jié)下 TCP 參數(shù)調(diào)優(yōu)的幾個(gè)細(xì)節(jié)，沒想到TCP 牽扯出來的東西實(shí)在太多，光是一個(gè)簡單的握手、揮手流程就存在這么多的細(xì)節(jié)和坑。
可以說為了保證數(shù)據(jù)傳輸?shù)目煽啃裕缙诘脑O(shè)計(jì)者確實(shí)考慮了太多的東西。當(dāng)然，這也為上層的應(yīng)用實(shí)現(xiàn)鋪平了道路。
兩年嘔心瀝血的文章：「面試題」「基礎(chǔ)」「進(jìn)階」這里全都有！
長按掃碼可關(guān)注獲取?
在看和分享對(duì)我非常重要！