Python學習【TCP/IP】

TCP與UDP的區(qū)別

1.TCP是面向連接的傳輸協(xié)議，傳輸前雙方需建立連接通道，而UDP可以直接傳輸。

2.TCP傳輸信息可靠，信息傳輸無差錯，不丟失，不重復，且按序到達。UDP傳輸不保證可靠。

3.TCP是字節(jié)流傳輸（較長數(shù)據(jù)分割成數(shù)據(jù)塊進行傳輸），而UDP是報文流傳輸（給多少傳多少）。

4.TCP為了實現(xiàn)傳輸可靠性使用了較為復雜的算法和實現(xiàn)過程，不適用于實時傳輸，UDP實時性較好。

5.每一條TCP連接只能是點對點的，UDP支持一對一，一對多，多對一，多對多。

6.TCP占用系統(tǒng)資源較多，UDP相對較少。

TCP三次握手的具體過程? 并解釋為什么需要三次握手?

第一次握手：客戶端向服務端發(fā)出請求，發(fā)送SYN包（同步序列編號）到客戶端，并進入SYN_SENT狀態(tài)。

第二次握手：服務端獲取到SYN包后，需要回復確認ACK，同時發(fā)送自己的SYN，并進入SYN_RECV狀態(tài)。

第三次握手：客戶端獲取到服務端發(fā)送的ACK和SYN后，需要回復確認ACK，發(fā)送完畢后，兩端同時進入ESTABLISHED（TCP連接成功）狀態(tài)，完成三次握手。

分析：

TCP可視為全雙工通信，分為兩個通信方向：Client>>Server / Server>>Client。

第一次握手：客戶端提交數(shù)據(jù)傳輸請求。
(C提交申請，但C自身并不知道C>>S 和S>>C是否可行)

第二次握手：服務端應答客戶端，表示確認接收到客戶端數(shù)據(jù)，并發(fā)出SYN，等待客戶端應答。
(S對C的請求進行應答，S可確認C>>S可行，但不知道S>>C是否可行)

第三次握手：客戶端應答服務端，表示確認接收到服務端數(shù)據(jù)，建立連接。
(C對S請求進行應答，C可知S>>C和C>>S均可行，S接收應答后可知S>>C可行，即可建立連接)

三次握手是對可靠傳輸進行確認的必要過程，完成三次握手可確保信息傳輸?shù)目煽啃浴Ｔ趦啥宋创_認的情況下進行傳輸，可能會導致信息重發(fā)等問題出現(xiàn)。

TCP四次斷開連接的過程， 并分析為什么斷開需要四次?

第一步，當主機A的應用程序通知TCP數(shù)據(jù)已經(jīng)發(fā)送完畢時，TCP向主機B發(fā)送一個帶有FIN附加標記的報文段（FIN表示英文finish）。

第二步，主機B收到這個FIN報文段之后，并不立即用FIN報文段回復主機A，而是先向主機A發(fā)送一個確認序號ACK，同時通知自己相應的應用程序：對方要求關(guān)閉連接（先發(fā)送ACK的目的是為了防止在這段時間內(nèi)，對方重傳FIN報文段）。

第三步，主機B的應用程序告訴TCP：我要徹底的關(guān)閉連接，TCP向主機A送一個FIN報文段。

第四步，主機A收到這個FIN報文段后，向主機B發(fā)送一個ACK表示連接徹底釋放。

分析：

同樣，關(guān)閉連接前要兩端都確認自己本端和對端數(shù)據(jù)傳輸完畢。即獲取對方發(fā)送的FIN并應答(ACK)告訴對方自己獲取到了對方的FIN。

第一步，A主機給發(fā)給B主機的消息傳輸完畢，向B發(fā)送FIN，告知B自己發(fā)送完畢，準備關(guān)閉連接。
（此時A傳輸完畢發(fā)出FIN，但不知道B是否發(fā)送完畢，也不知道B是否接收到自己的FIN報文）

第二步，B主機在未發(fā)送完畢的情況下接收到A的FIN，向A回復ACK且通知本機應用層，并將未發(fā)送完畢的數(shù)據(jù)繼續(xù)發(fā)送完。
（B得知A發(fā)送完畢，A接收ACK后得知B接收到自己發(fā)送的FIN報文）

第三步，B主機發(fā)送完畢后，發(fā)出FIN報文，并等待A的應答（2MSL內(nèi)沒有收到A的應答，則重發(fā)）
（B傳輸完畢，但不知道A是否接收到自己的FIN報文）
（MSL指一個片段在網(wǎng)絡中最大的存活時間，2MSL就是一個發(fā)送和一個回復所需的最大時間）

第四步，A收到B的FIN報文，做出ACK應答，在等待2MSL后自行關(guān)閉。
（A應答，B收到后得知A收到了自己的FIN報文，B關(guān)閉，A在2MSL內(nèi)沒有收到B的FIN重發(fā)，判斷B已經(jīng)收到了自己的ACK，A關(guān)閉）

四次揮手可以看作是改良版的三次握手，只不過在第二次握手時考慮到B端數(shù)據(jù)沒有發(fā)送完畢的情況，因此ACK和FIN分兩次進行發(fā)送，變成了四次。