傳輸層:TCP 和 UDP
三次握手(three-way handshake)
第一次握手: Client將SYN置1,隨機產生一個初始的序列號seq發送給Server，進入SYN_SENT狀態
第二次握手: 收到SYN爲1之後,知道客戶端請求建立連接,將自己的SYN置爲1,ACK置爲1,產生一個acknowledge number = sequence number + 1,並隨機產生一個自己的初始序列號,發送給客戶端,進入SYN_RCVD狀態
第三次握手: 客戶端檢查acknowledge number是否爲序列號+1，ACK是否爲1，檢查正確之後將自己的ACK置爲1，產生一個acknowledge number=服務器發的序列號+1，發送給服務器；進入ESTABLISHED狀態；服務器檢查ACK爲1和acknowledge number爲序列號+1之後，也進入ESTABLISHED狀態；完成三次握手，連接建立。
TCP不能建立連接考研兩次握手的原因
本來的樣子 :Client發出的第一個鏈接請求報文段並沒有丟失,而是在某個網絡結點長時間滯留了,以至於延誤到麗娜姐釋放後的某個時間到達server,但在他收到一腳的報文段後誤以爲C端又發了一個新的鏈接請求,於是向C端發出確認報文段,同意建立連接.
具體的過程 :假設不採取,只要S端確認,新的鏈接就建立了.由於C端並沒有發出建立鏈接的請求,因此不會理睬S的確認,也不會向S端發送數據,但S端卻以爲新的運輸鏈接已經建立,於是一直等待C端發來數據.S的很多數據就浪費掉了.
簡單來說 :C不會向S的確認發出確認,S由於得不到確認,就認爲C端沒有要求建立連接.
可以採用四次握手嗎?
可以.但是會降低傳輸的效率.第四次握手是指:
第二次握手:S端whiffsACK和acknowledge number,二S端的SYN和初始化序列在第三次時發送,原來協議中的第三次變成第四次握手. 出於優化目的,二三次可以合併
第三次握手中，如果客戶端的ACK未送達服務器，會怎樣?
由於S端沒接受到ACK確認,因此會重發之前的SYN+ACK(默認五次之後自動關閉連接)
C端收到後會重新傳ACK給S端.
如果C端向服務器發送數據,服務器會以RST包響應.
如果已經建立了連接,客戶端出現了故障怎麼辦
服務器沒收到一次客戶端的請求後都會重新復位一個計時器,時間通常是2小時,弱之後還沒有收到客戶端的任何數據,服務器就會發送一個探測報文段,每隔75秒發送一個探測報文段,10個之後還是沒有反應,就認爲是故障了,關閉連接.
初始序列號是什麼
TCP連接的一方A，隨機選擇一個32位的序列號（Sequence Number）作爲發送數據的初始序列號（Initial Sequence Number，ISN），比如爲1000，以該序列號爲原點，對要傳送的數據進行編號：1001、1002…三次握手時，把這個初始序列號傳送給另一方B，以便在傳輸數據時，B可以確認什麼樣的數據編號是合法的；同時在進行數據傳輸時，A還可以確認B收到的每一個字節，如果A收到了B的確認編號（acknowledge number）是2001，就說明編號爲1001-2000的數據已經被B成功接受。
什麼是四次揮手
第一次揮手 C端將FIN置1,發送一個序列號seq給Server; 進入FIN_WAIT——1 狀態
第二次揮手 收到之後發送一個ACK= 1,acknowledge number = 收到的序列號+1；進入CLOSE_WAIT狀態。此時客戶端已經沒有要發送的數據了，但仍可以接受服務器發來的數據。次揮手
第三次揮手 Server將FIN置1，發送一個序列號給Client；進入LAST_ACK狀態；
第四次揮手 C端收到服務器 FIN後,進入TIME_WAIT狀態；接着將ACK置1，發送一個acknowledge number=序列號+1給服務器；服務器收到後，確認acknowledge number後，變爲CLOSED狀態，不再向客戶端發送數據。客戶端等待2*MSL（報文段最長壽命）時間後，也進入CLOSED狀態。
爲什麼不能吧服務器發給ACK和FIN合併起來,變成第三次揮手
因爲服務器收到客戶端斷開連接的請求時，可能還有一些數據沒有發完，這時先回復ACK，表示接收到了斷開連接的請求。等到數據發完之後再發FIN，斷開服務器到客戶端的數據傳送.(CLOSE_WAIT狀態意義是什麼?)
如果第二次揮手時服務器的ACK沒有送達客戶端會怎麼樣
客戶端沒有收到ACK確認,會重新發送FIN請求
客戶端TIME_WAIT狀態的意義是什麼?
第四次揮手時，客戶端發送給服務器的ACK有可能丟失，TIME_WAIT狀態就是用來重發可能丟失的ACK報文。如果Server沒有收到ACK，就會重發FIN，如果Client在2*MSL的時間內收到了FIN，就會重新發送ACK並再次等待2MSL，防止Server沒有收到ACK而不斷重發FIN。
MSL(Maximum Segment Lifetime)，指一個片段在網絡中最大的存活時間，2MSL就是一個發送和一個回覆所需的最大時間。如果直到2MSL，Client都沒有再次收到FIN，那麼Client推斷ACK已經被成功接收，則結束TCP連接。
TCP如何實現流量控制
使用滑動窗口協議實現流量控制。防止發送方發送速率太快，接收方緩存區不夠導致溢出。接收方會維護一個接收窗口 receiver window（窗口大小單位是字節），接受窗口的大小是根據自己的資源情況動態調整的，在返回ACK時將接受窗口大小放在TCP報文中的窗口字段告知發送方。發送窗口的大小不能超過接受窗口的大小，只有當發送方發送並收到確認之後，才能將發送窗口右移。發送窗口的上限爲接受窗口和擁塞窗口中的較小值。接受窗口表明了接收方的接收能力，擁塞窗口表明了網絡的傳送能力。
什麼是零窗口(接受窗口爲0時會怎樣)
如果接收方沒有能力接收數據，就會將接收窗口設置爲0，這時發送方必須暫停發送數據，但是會啓動一個持續計時器(persistence timer)，到期後發送一個大小爲1字節的探測數據包，以查看接收窗口狀態。如果接收方能夠接收數據，就會在返回的報文中更新接收窗口大小，恢復數據傳送。
TCP的擁堵控制是怎麼實現的?
控制阻塞的四個算法:慢啓動（Slow Start）、擁塞避免（Congestion voidance）、快重傳 （Fast Retransmit）、快恢復（Fast Recovery）
慢啓動：剛開始發送數據時，先把擁塞窗口（congestion window）設置爲一個最大報文段MSS的數值，每收到一個新的確認報文之後，就把擁塞窗口加1個MSS。這樣每經過一個傳輸輪次（或者說是每經過一個往返時間RTT），擁塞窗口的大小就會加倍
擁塞避免：當擁塞窗口的大小達到慢開始門限(slow start threshold)時，開始執行擁塞避免算法，擁塞窗口大小不再指數增加，而是線性增加，即每經過一個傳輸輪次只增加1MSS. 無論在慢開始階段還是在擁塞避免階段，只要發送方判斷網絡出現擁塞（其根據就是沒有收到確認），就要把慢開始門限ssthresh設置爲出現擁塞時的發送方窗口值的一半（但不能小於2）。然後把擁塞窗口cwnd重新設置爲1，執行慢開始算法。（這是不使用快重傳的情況）
快重傳：快重傳要求接收方在收到一個失序的報文段後就立即發出重複確認（爲的是使發送方及早知道有報文段沒有到達對方）而不要等到自己發送數據時捎帶確認。快重傳算法規定，發送方只要一連收到三個重複確認就應當立即重傳對方尚未收到的報文段，而不必繼續等待設置的重傳計時器時間到期。
1快恢復：當發送方連續收到三個重複確認時，就把慢開始門限減半，然後執行擁塞避免算法。不執行慢開始算法的原因：因爲如果網絡出現擁塞的話就不會收到好幾個重複的確認，所以發送方認爲現在網絡可能沒有出現擁塞也有的快重傳是把開始時的擁塞窗口cwnd值再增大一點，即等於 ssthresh + 3*MSS 。這樣做的理由是：既然發送方收到三個重複的確認，就表明有三個分組已經離開了網絡。這三個分組不再消耗網絡的資源而是停留在接收方的緩存中。可見現在網絡中減少了三個分組。因此可以適當把擁塞窗口擴大些。