一.概述
傳輸層位于七層模型的第四層，用戶功能里面的最底層，面向通信部分的最高層
傳輸層工作的位置是終端設備，網(wǎng)絡中的路由器沒有傳輸層
傳輸層負責管理端到端的通信連接
進程與進程的通信
使用端口號（Port）來標記不同的網(wǎng)絡進程
端口（Port）使用16比特位表示（0～65535）
UDP協(xié)議
UDP（User Datagram Protocol）用戶數(shù)據(jù)報協(xié)議
UDP協(xié)議的位置
UDP協(xié)議的首部
源端口號：源機器使用網(wǎng)絡的進程
目的端口號：目的機器正在使用的網(wǎng)絡進程
UDP長度：UDP數(shù)據(jù)報的長度
校驗和：檢測UDP數(shù)據(jù)報在傳輸過程中是否出錯
UDP特點
UPD是無連接協(xié)議
UDP不能保證可靠的交付數(shù)據(jù)（想發(fā)就發(fā)，無法保證數(shù)據(jù)在網(wǎng)絡中是否丟失）
UDP是面向報文傳輸?shù)模嫦驁笪模簯脤觽鱽淼臄?shù)據(jù)報）
UDP沒有擁塞控制（把網(wǎng)絡比做一條公路，UDP不管網(wǎng)絡是否發(fā)生擁塞，都會盡量把數(shù)據(jù)交付出去給網(wǎng)絡）
UDP的首部開銷很?。ㄊ撞块_銷：源端口號，目的端口號，數(shù)據(jù)長度，校驗和這四部分）
TCP協(xié)議
TCP（Transmission Control Protocol）傳輸控制協(xié)議
TCP協(xié)議的特點
TCP是面向連接的協(xié)議
TCP的一個連接有兩端（點對點通信）
TCP提供可靠的傳輸服務
TCP協(xié)議提供全雙工的通信（全雙工：兩端可以同時發(fā)出數(shù)據(jù)和接收數(shù)據(jù)）
TCP是面向字節(jié)流的協(xié)議（UDP是面向數(shù)據(jù)報的協(xié)議，TCP面向字節(jié)流，字節(jié)流是流入進程和流出進程的字節(jié)序列，TCP不把應用層的數(shù)據(jù)看作一整塊，而是看作一系列的字節(jié)流，可能會對用戶數(shù)據(jù)進行拆分和合并進行發(fā)送）
可靠傳輸?shù)幕驹?/h3>
停止等待協(xié)議，連續(xù)ARQ協(xié)議
停止等待協(xié)議
發(fā)送方發(fā)送消息到接收方，接收方接收到消息后生成確認消息，發(fā)送給發(fā)送方，發(fā)送方收到確認消息后再生成消息2發(fā)送給接收方。在這幾次消息發(fā)送和接收過程中，雙方都要等待對方的消息接收到之后再發(fā)送新的消息。發(fā)送方發(fā)送消息后就停止生成新的消息，等待接收方的確認消息到達發(fā)送方后再生成第二個消息。
連續(xù)ARQ協(xié)議
//待補充
滑動窗口協(xié)議
//待補充
TCP報文頭部
其他部分待補充...
TCP標記
TCP連接的建立
設主機B接收方運行一個服務器進程，它先發(fā)出一個被動打開命令，告訴它的TCP要準備接收客戶進程的連續(xù)請求，然后服務進程就處于聽的狀態(tài)。不斷檢測是否有客戶進程發(fā)起連續(xù)請求，如有，作出響應。設主機A作為發(fā)送方，它先向自己的TCP發(fā)出主動打開的命令，表明要向某個IP地址的某個端口建立運輸連接?？蛻舳税l(fā)送的第一個數(shù)據(jù)包是一個請求報文段，報文內(nèi)容包括同步位SYN=1，另一個是初始序號seq=x.TCP規(guī)定，SYN=1的報文不能攜帶數(shù)據(jù)，但是消耗一個序列號?？蛻舳税l(fā)送了這個報文之后，進入SYN-SENT（同步已發(fā)送）狀態(tài)。
服務端已收到這個數(shù)據(jù)包之后，知道客戶端請求連接，如果當前有資源，可以同意連接，則給客戶端發(fā)送確認報文。確認報文的內(nèi)容包括SYN=1（沒有變化），seq=y(服務端的序列號)，新增ACK=1，ack=x+1(客戶端序列號+1)這里的SYN=1，所以報文不能攜帶數(shù)據(jù)，同樣消耗了服務端的一個序列號，然后服務端進入了SYN-RCVD（同步收到）狀態(tài)。
客戶端收到服務端的確認報文后，還需要給服務端發(fā)送一個確認報文。這個報文的內(nèi)容是ACK=1，seq=x+1,ack=y+1.這里沒有了SYN字段，可以攜帶數(shù)據(jù)?？蛻舳舜_認報文發(fā)送出去之后，客戶端進入ESTABLISKED(已建立連接)
服務端接收到這個數(shù)據(jù)包之后，也進入了ESTABLISHED（已建立連接）狀態(tài)。
為什么發(fā)送方要發(fā)出第三個確認報文呢？
首先建立連接，必須要有兩次握手吧，客戶端主動一次，告知服務端，我想和你建立連接，然后看服務端是否同意。然后如果服務端同意的話，得給一個回復，然后開始等待客戶端的數(shù)據(jù)包，這就是兩次握手。如果這個時候就建立連接，客戶端開始給服務端發(fā)送數(shù)據(jù)包，在正常情況下沒啥問題。但是由于網(wǎng)絡并不是100%任何時候都穩(wěn)定，一旦因為某些原因?qū)е路斩税l(fā)送給客戶端的確認報文丟失，那這個時候客戶端收不到確認數(shù)據(jù)包，會誤以為服務端不同意連接，不會給服務端發(fā)送數(shù)據(jù)包，但是這時候服務端已經(jīng)在等待了。這樣的差錯會導致服務端一直處于等待狀態(tài)，浪費資源。
? ? ? ? 而三次握手的話，客戶端在確認服務端同意之后再發(fā)一次數(shù)據(jù)包給服務端，告知服務端，不管怎么樣我都會給你發(fā)送數(shù)據(jù)包的。因為TCP協(xié)議中，建立連接之后，每一次發(fā)送數(shù)據(jù)包客戶端都會等待服務端的確認信息，如果收不到某一個數(shù)據(jù)包的確認信息，客戶端就會重發(fā)這個數(shù)據(jù)包。這樣就不會發(fā)生差錯了。
已經(jīng)失效的鏈接請求報文傳送到對方引起錯誤
TCP連接的釋放
?當TCP連接需要釋放時，客戶端和服務端都是處于ESTABLISHED（已建立連接）狀態(tài)。此時，客戶端數(shù)據(jù)發(fā)送完畢，想要結(jié)束連接，主動發(fā)出連接釋放請求數(shù)據(jù)包。這個數(shù)據(jù)包內(nèi)容：Fin=1，seq=u（這個u是這個數(shù)據(jù)包之前一個數(shù)據(jù)包的序列號+1），客戶端進入FIN-WAIT-1（終止等待1）狀態(tài)，不再發(fā)送數(shù)據(jù)包，等待服務端的確認。
服務端接收到釋放數(shù)據(jù)包之后發(fā)出確認，確認包中內(nèi)容：確認號ack=u+1，序列號seq=v（這個v是服務端上一個發(fā)送的數(shù)據(jù)包的序列號+1），另一個是ACK=1。然后服務端進入CLOSE-WAIT（關閉等待）。這個時候客戶端到服務端的連接已經(jīng)結(jié)束了。但是TCP是全雙工通信，因為這個時候是客戶端主動發(fā)起的結(jié)束，在服務端這邊可能還存在著數(shù)據(jù)沒有完全發(fā)送給客戶端，所以服務端到客戶端仍然沒有結(jié)束?？蛻舳艘呀?jīng)不能在發(fā)送數(shù)據(jù)了，如果服務端還有數(shù)據(jù)發(fā)送過來，客戶端仍然要接收。
? ? ? ? 客戶端收到服務端的確認之后，進入FIN-2（終止等待2）狀態(tài)，等待服務端發(fā)送服務端發(fā)器的連接釋放數(shù)據(jù)包。這時候服務端可能還有一些數(shù)據(jù)包要發(fā)送給客戶端，客戶端一一接收。最后，沒有數(shù)據(jù)要發(fā)送了之后，服務端發(fā)送連接釋放數(shù)據(jù)包，這個數(shù)據(jù)包內(nèi)容：FIN=1，ACK=1，seq=w（因為在服務端回復客戶端的連接請求（數(shù)據(jù)包的序列號是v）之后，可能仍然有其他數(shù)據(jù)包要發(fā)送，所以這里的w不一定是v+1），ack=u+1（確認號和上次回復客戶端的請求釋放連接的確認號一樣）。接著服務端進入LAST-ACK（最后確認狀態(tài)），等待客戶端的確認。
客戶端收到服務端的連接釋放數(shù)據(jù)包之后，發(fā)出一個確認數(shù)據(jù)包，內(nèi)容：ACK=1，seq=u+1，ack = w+1。然后客戶端進入TIME-WAIT（時間等待）狀態(tài)。這個時候TCP還沒有釋放。仍需要經(jīng)過時間等待計時器設置的時間2MSL后，客戶端才會進入CLOSED狀態(tài)。MSL稱為最長報文段壽命。RFC793建議把這個值設為2分鐘，那這樣的話，在客戶端收到服務端的連接釋放數(shù)據(jù)包之后，需要等待4分鐘才能進入CLOSED狀態(tài)。這顯然時間太長了，不過這個值設為2分鐘也只是建議，還是可以設置適合的時間的。最后服務端收到這個客戶端的確認包之后就進入了CLOSED狀態(tài)。顯然，服務端一般先于客戶端進入關閉狀態(tài)。
之所以客戶端需要等待2MSL時間才完全結(jié)束TCP連接，原因有兩個：
一、為了保證客戶端發(fā)送的最后一個確認包能正確到達服務端。因為如果由于網(wǎng)絡原因丟失的話，服務端會重新發(fā)送連接釋放數(shù)據(jù)包，在等待過程中，如果真的發(fā)生這種情況就可以得到處理?？蛻舳嗣拷邮盏揭淮畏斩税l(fā)送來的接釋放數(shù)據(jù)包都會重新設置時間等待計時器，然后等待2MSL時間才完全結(jié)束TCP連接。
二、等待才2MSL時間完全結(jié)束TCP連接，可以避免再次開啟TCP連接的時候收到上一次TCP連接存在網(wǎng)絡中的數(shù)據(jù)包，顯然這樣的數(shù)據(jù)包不是屬于本次連接的，是無效的數(shù)據(jù)包。
? ? ? ?之所以需要四次握手來釋放連接，TCP是全雙工通信，支持兩個方向通信，所以結(jié)束的時候，每個方向為了確保數(shù)據(jù)都能完全從一端到達另一端，所以結(jié)束的時候，一端發(fā)起結(jié)束申請數(shù)據(jù)包，另一端都要發(fā)送確認數(shù)據(jù)包。兩個方向要分開結(jié)束，每次結(jié)束需要兩次握手，所以最終TCP的結(jié)束需要4次握手。
