學(xué)習(xí)TCP/IP，一定要看這個圖。它對排除和定位網(wǎng)絡(luò)或系統(tǒng)故障時大有幫助。
傳輸控制協(xié)議TCP簡介：
1.面向連接的，可靠的，基于字節(jié)流的傳輸層通信協(xié)議。
2.將應(yīng)用層的數(shù)據(jù)流分割成報文段并發(fā)送給目標(biāo)節(jié)點的TCP層。
3.數(shù)據(jù)包都有序號，對方收到則發(fā)送ACK確認(rèn)，未收到則重傳。如果發(fā)送端d在RTT(一個連接的往返時間，即數(shù)據(jù)發(fā)送時刻到接收到確認(rèn)的時刻的差值)未收到確認(rèn)，對應(yīng)的數(shù)據(jù)會假設(shè)被丟失。
4.TCP用奇偶校驗函數(shù)來校驗檢驗數(shù)據(jù)在傳輸過程中是否有誤。
TCP Flags:
1.URG：緊急指針標(biāo)志。
2.ACK：確認(rèn)序號標(biāo)志。
3.PSH：push標(biāo)志。
4.RST：重置連接標(biāo)志。
5.SYN：同步序號，用于建立連接過程。
6.FIN：finish標(biāo)志，用于釋放連接。
用于建立連接過程，在連接請求中，
SYN=1和ACK=0表示該數(shù)據(jù)段沒有使用捎帶的確認(rèn)域，而連接應(yīng)答捎帶一個確認(rèn)域，即SYN=1和ACK=1(捎帶是指對客戶機(jī)到服務(wù)器數(shù)據(jù)的確認(rèn)被裝載在一個承載服務(wù)器到客戶機(jī)的數(shù)據(jù)報文段中)
在TCP/IP協(xié)議中，TCP協(xié)議提供可靠的連接服務(wù)，采用三次握手建立一個連接。
第一次握手:建立連接時，客戶端發(fā)送SYN包(seq=x)到服務(wù)器，并進(jìn)入SYN_SEND狀態(tài)，等待服務(wù)器確認(rèn)。
第二次握手：服務(wù)器收到SYN包，必須確認(rèn)客戶的SYN(ack=x+1)，同時自己也發(fā)送一個SYN包(seq=y)，此時是SYN+ACK包，此時服務(wù)器進(jìn)入到SYN_RECV狀態(tài)。
第三次握手：客戶端收到服務(wù)器的SYN+ACK包，向服務(wù)器發(fā)送確認(rèn)包ACK(seq = x+1，ack = y+1)。此包發(fā)送完畢后，客戶端和服務(wù)器進(jìn)入到ESTABLISHED狀態(tài)完成三次握手。
為什么需要三次握手才能建立起連接？是因為為了初始化Sequence Number的初始值。
首次握手的隱患-SYN超時，Server收到Client的SYN，回復(fù)SYN-ACK的時候未收到ACK的確認(rèn)。Server不斷的重試直到超時，Linux默認(rèn)等待63秒才斷開連接。那這樣讓服務(wù)器遭到SYN Flood的攻擊，惡意程序會給SYN報文，然后就下線了。然后服務(wù)器默認(rèn)要等待63s才會斷開連接。這樣攻擊者會把服務(wù)器的SYN連接隊列耗盡，讓正常連接的請求不能得到處理。
針對SYN Flood的防護(hù)措施：
1.SYN隊列滿后，通過tcp_syncookies(源地址端口+目標(biāo)地址端口+時間戳)參數(shù)回發(fā)SYN Cookie
2.若為正常連接則Client會回發(fā)Syn Cookie，直接建立連接。就算本次請求不在Syn隊列中也能正常建立連接。
建立連接后，Client出現(xiàn)故障怎么辦?可以使用?；顧C(jī)制：
1.向?qū)Ψ桨l(fā)送?；钐綔y報文，如果未收到相應(yīng)則繼續(xù)發(fā)送。
2.嘗試次數(shù)達(dá)到保活探測數(shù)仍未收到響應(yīng)則中斷連接。
TCP采用了四次揮手來釋放連接
第一次揮手：Client發(fā)送了一個FIN，用于關(guān)閉Client到Server的數(shù)據(jù)傳輸，Client既然怒到FIN_WAIT_1狀態(tài)。
第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認(rèn)序號為收到序號+1(與SYN相同，一個FIN占用一個序號)，Server進(jìn)入CLOSE_WAIT狀態(tài)。
第三次揮手：Server發(fā)送一個FIN，用于關(guān)閉Server到Client的數(shù)據(jù)傳送，Server進(jìn)入到LAST_ACK狀態(tài)。
第四次揮手：Client收到FIN后，Client進(jìn)入TIME_WAIT狀態(tài)，接著發(fā)送一個ACK給Server，確認(rèn)序號為收到序號+1，Server進(jìn)入到CLOSED狀態(tài)，完成四次揮手。
為什么會有TIME_WAIT狀態(tài)？
1.確保有足夠的時間讓對方收到ACK包。如果被關(guān)閉的一方?jīng)]有收到ACK，會觸發(fā)被關(guān)閉的一方重發(fā)FIN包，就是2MSL。
2.避免新舊連接混淆。
為什么需要四次握手才能斷開連接？因為全雙工，發(fā)送方和接收方都需要FIN報文和ACK報文。
為什么會出現(xiàn)CLOSE_WAIT狀態(tài)的原因？
1.對方關(guān)閉Socket連接，我方忙于讀或?qū)?，沒有及時關(guān)閉連接。(檢查代碼，特別時釋放資源的代碼。檢查配置，特別是處理請求的線程配置)
UDP的特點：
1.面向非連接。
2.不維護(hù)連接狀態(tài)，支持同時向多個客戶端傳輸相同的消息。
3.數(shù)據(jù)包報頭只有8個字節(jié)(TCP是20個字節(jié))，額外開銷較小。
4.吞吐量只受限于數(shù)據(jù)生成速率，傳輸速率以及機(jī)器性能。
5.盡最大努力交付，不保證可靠交付，不需要維持復(fù)雜的連接狀態(tài)表。
6.面向報文，不對應(yīng)用程序提交的報文信息進(jìn)行拆分或者合并。
TCP 和UDP的區(qū)別：
1，TCP是面向連接(Connection oriented)的協(xié)議，UDP是無連接(Connection less)協(xié)議；
2，TCP無界，UDP有界；
3，TCP可靠，UDP不可靠；由于TCP要保證所有的數(shù)據(jù)包都可以到達(dá)，所以，需要有重傳機(jī)制（快重傳，快恢復(fù)，超時重傳），UDP不會進(jìn)行重傳。
4，TCP有序，UDP無序；消息在傳輸過程中可能會亂序，后發(fā)送的消息可能會先到達(dá)，TCP會對其進(jìn)行重排序，UDP不會。
5，TCP有流量控制（擁塞控制），UDP沒有；
6，TCP的頭部比UDP大；TCP頭部20 bytes
RTT(Round Trip Time):發(fā)送一個數(shù)據(jù)包到收到對應(yīng)的ACK所花費(fèi)的時間。
RTO(Retransmission TimeOut)：重傳時間間隔。
滑動窗口協(xié)議，是TCP使用的一種流量控制方法。該協(xié)議允許發(fā)送方在停止并等待確認(rèn)前可以連續(xù)發(fā)送多個分組。由于發(fā)送方不必每發(fā)一個分組就停下來等待確認(rèn)，因此該協(xié)議可以加速數(shù)據(jù)的傳輸。
只有在接收窗口向前滑動時（與此同時也發(fā)送了確認(rèn)），發(fā)送窗口才有可能向前滑動。
