- 相關(guān)推薦
TCP/IP傳輸層
TCP:傳輸控制協(xié)議,是TCP/IP參考模型的傳輸層協(xié)議。那么關(guān)于TCP/IP傳輸層，你懂多少?下面跟yjbys小編一起來(lái)學(xué)習吧!
一、傳輸層的主要功能是什么?
分割并重新組裝上層提供的數據流，為數據流提供端到端的傳輸服務(wù)
二、傳輸層如何區分不同應用程序的數據流?
因為，對應傳輸層而言，它只需要知道目標主機上的哪個(gè)服務(wù)程序來(lái)響應這個(gè)程序，而不需要知道這個(gè)服務(wù)程序是干什么的。因此，我們只需要能夠抽象的表示出來(lái)這些應用程序和服務(wù)程序即可。我們使用端口號來(lái)抽象標識每個(gè)網(wǎng)絡(luò )程序。
|
傳輸層的TCP和UDP可以接收來(lái)自多個(gè)應用程序的數據流，用端口號標識他們，然后把他們送給Internet層處理； 同時(shí)TCP和UDP接收來(lái)自Internet層的數據包，用端口號區分他們，然后交給不同的應用程序。 |
因此：在同一IP地址(同一個(gè)目標主機)上不同的端口號是兩個(gè)不同的鏈接。IP地址和端口號用來(lái)唯一的確定網(wǎng)絡(luò )上數據的目的地。
三、傳輸層有哪些協(xié)議?
傳輸層的兩大協(xié)議：TCP(傳輸控制協(xié)議)UDP(用戶(hù)數據包協(xié)議)
TCP是一個(gè)可靠的面向鏈接的協(xié)議，UDP是不可靠的或者說(shuō)無(wú)連接的協(xié)議。
可以用打電話(huà)和發(fā)短信來(lái)說(shuō)明這種關(guān)系：
UDP就好似發(fā)短信，只管發(fā)出去，至于對方是不是空號(網(wǎng)絡(luò )不可到達)能不能收到(丟包)等并不關(guān)心。
TCP好像打電話(huà)，雙方要通話(huà)，首先，要確定對方不是開(kāi)機(網(wǎng)絡(luò )可以到達)，然后要確定是不是沒(méi)有信號()，然后還需要對方接聽(tīng)(通信鏈接)。
四、什么是UDP協(xié)議?
UDP數據包結構如下圖所示
|
源端口(16) |
目標端口(16) |
|
報文長(cháng)度(16) |
校驗和(16) |
|
數據（可變） |
|
UDP為應用程序提供的是一種不可靠的、無(wú)連接的分組交付，因此，UDP報文可能會(huì )出現丟失、亂序、重復、延時(shí)等問(wèn)題。
| 因為它不提供可靠性，它的開(kāi)銷(xiāo)很小。 |
五、為什么有了UDP，還需要TCP?
問(wèn)題4中已經(jīng)說(shuō)到，UDP為應用程序提供的是一種無(wú)連接、不可靠的分組交付。當網(wǎng)絡(luò )硬件失效或者負擔太重時(shí)，數據包可能就會(huì )產(chǎn)生丟失、重復、延時(shí)、亂序的現象。這些都會(huì )導致我們的通信不正常。如果讓?xiě)贸绦騺?lái)?yè)摬铄e控制的工作，無(wú)疑將給程序員帶來(lái)許多復雜的工作，于是，我們使用獨立的通信協(xié)議來(lái)保證通信的可靠性是非常必要的。
六、什么是TCP協(xié)議?
傳輸控制協(xié)議TCP是一個(gè)面向鏈接的、可靠的通信協(xié)議。
1. 在開(kāi)始傳輸前，需要進(jìn)行三次握手建立鏈接
2. 可靠性：在傳輸過(guò)程中，通信雙方的協(xié)議模塊繼續進(jìn)行通信
3. 通信結束后，通信雙方都會(huì )使用改進(jìn)的三次握手來(lái)關(guān)閉鏈接
TCP數據包結構如下圖
|
源端口(16) |
目標端口(16) |
||
|
序號(32) |
|||
|
應答號(32) |
|||
|
頭長(cháng)度(4) |
保留(6) |
編碼位(6) |
窗口(16) |
|
校驗和(16) |
緊急(16) |
||
|
可選項(如果有，0或32) |
|||
|
數據(可變) |
|||
七、怎么理解協(xié)議和程序?
如同我們自定義的應用層協(xié)議一樣：協(xié)議只是給出了一組規范，規定我們應該怎么樣(按什么規則)保存數據。
在計算機間傳輸的永遠都是二進(jìn)制字節碼(對于傳輸層，可以理解為傳輸的始終是下層的IP數據包)，是計算機中的程序通過(guò)對這些字節碼進(jìn)行邏輯分析、判斷，來(lái)控制程序完成差錯控制等功能。
至于解析這些字節碼的程序，則可以有不同的實(shí)現，只要我們按照規則來(lái)解析，并作出相應的控制，我們大可以自己寫(xiě)個(gè)程序是實(shí)現相應功能。
|
知道了這些后，顯然，我們也可以使用前面說(shuō)的Jpcap，來(lái)自己實(shí)現一個(gè)基于Java的TCP或者UDP協(xié)議�？梢詤⒖糒inux下的Tcp源碼。
/net/ipv4/udp.c |
八、TCP是否真的有鏈接?
我們都知道，TCP通過(guò)完成三次握手來(lái)建立鏈接的，但是這種連接是面向虛電路的，是物理上不存在的，只是雙方的TCP程序，邏輯上的認為建立了這樣的鏈接。
九、鏈接是如何建立的(邏輯上)?
假設：當我們在主機A上啟動(dòng)一個(gè)程序，通過(guò)TCP去鏈接主機B上的9091端口。
整個(gè)過(guò)程是怎么樣的呢?邏輯上我們可以這么理解建立鏈接的過(guò)程：
1.SYN:seq=X;
1.1 A的TCP程序，為這個(gè)鏈接分配一個(gè)端口(設為9090)。
1.2 同時(shí)邏輯上的將TCP連接的狀態(tài)設置為：正在連接。(通過(guò)在鏈接狀態(tài)表中添加一條記錄，記錄中狀態(tài)為：正在連接)
猜想：
|
TCP程序中， 應該有張表來(lái)保持鏈接的狀態(tài)，其中每個(gè)狀態(tài)應該有： 本機地址（IP加port）、對方地址、鏈接狀態(tài) |
1.3 同時(shí)，隨機生成一個(gè)初始序列號X，生成一個(gè)TCP包，將初始化序列號X設置為T(mén)CP中的序列號，發(fā)送給主機B。
2.SYN:seq=Y ACK:ack=X+1;
2.1 B上TCP程序收到該數據包，查詢(xún)9091端口狀態(tài)，如果可以鏈接。
2.2 同樣的，在邏輯上的將TCP連接的狀態(tài)設置為：正在連接
2.3 同時(shí)，隨機生成一個(gè)初始化序列號Y，根據接收的序列號X，生成應答號X+1，生成一個(gè)TCP包，將序列號和應答號分別設置到TCP包頭中，將TCP數據包發(fā)給主機A。
3.SYN:seq=X+1 ACK:ack=Y+1.
3.1 A上的TCP程序接收到數據包，查詢(xún)9090端口狀態(tài)。
3.2 根據收到的SYN:seq=Y;ACK:ack=X+1; 封裝一個(gè)TCP包 SYN:seq=x+1;ACK:ack=Y+1;發(fā)送給主機B。同時(shí)，TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。
3.3 主機B收到數據包，TCP程序將鏈接狀態(tài)表中該條記錄狀態(tài)設置為已連接。
至此，一個(gè)TCP鏈接建立(三次握手)完成。
我們可以看到：
第一：傳送的都是IP數據包，其實(shí)只是將收到的數據包交給TCP程序處理。
第二：鏈接狀態(tài)，只是TCP程序中的一個(gè)邏輯狀態(tài)。
十：所謂的建立TCP鏈接開(kāi)銷(xiāo)很大，具體是指什么?
從九中，很容易看出。要簡(jiǎn)歷TCP鏈接，必須進(jìn)行三次IP數據包的成功傳輸。
十一：三次握手的目的是什么?
TCP是面向鏈接的，在面向鏈接的環(huán)境中，開(kāi)始傳輸數據之前，在兩個(gè)中端之間必須先建立一個(gè)鏈接。建立鏈接的過(guò)程可以確保通信雙方在發(fā)送應用程序數據包之前，都已經(jīng)準備好了傳送和接收數據。并且使通信雙方統一了初始化序列號。
十二：TCP如何提供可靠性?
在傳輸過(guò)程中，通信雙方的協(xié)議模塊繼續進(jìn)行通信，從而確保了傳輸的可靠性。
針對亂序：在通過(guò)三次握手進(jìn)行鏈接時(shí)，序列號被初始化。在傳輸過(guò)程中，TCP繼續使用這個(gè)序列號來(lái)標記發(fā)送的每一個(gè)數據段，沒(méi)傳送一個(gè)數據段，序列號加一。接收方依據序列號重裝收到的數據段。
針對丟包：在傳輸過(guò)程中，接收方收到一個(gè)數據段后，會(huì )用ACK應答碼向發(fā)送端回復一個(gè)IP包進(jìn)行應答，確認號ACK用來(lái)告訴發(fā)送端哪些數據包已經(jīng)成功接收，發(fā)送方對未被應答的報文段提供重傳。
針對重復：接收端收到數據段后，查看序列號，如果已經(jīng)成功接收改數據包，則丟棄后面這個(gè)數據段。
針對延時(shí)：延時(shí)造成的第一個(gè)問(wèn)題，就是數據包達到接收端時(shí)亂序。
當延時(shí)嚴重時(shí)，接收端一直未收到數據段，則不會(huì )回復ACK，發(fā)送端認為丟包，重發(fā)。
十三：什么是預期確認?什么是肯定確認與重新傳輸?哪些情況會(huì )重傳?
1.確認號ACK會(huì )告訴發(fā)送端哪些數據段已經(jīng)成功接收，并且確認號會(huì )向發(fā)送端指出接收端希望收到的下一個(gè)序列號。即，確實(shí)號ACK為上個(gè)數據序列號+1，這種機制稱(chēng)為預期確認。
2.為了提高效率，我們在發(fā)送端，將數據段保存在緩沖區中，直道發(fā)送端收到來(lái)自接收端的確認號。這種機制被稱(chēng)為“肯定確認與重新傳輸”。
3.當發(fā)送端在給定時(shí)間間隔內收不到那個(gè)數據段的應答時(shí)，發(fā)送端就會(huì )重傳那個(gè)數據段。
情況1：網(wǎng)絡(luò )延時(shí)/環(huán)路，數據段丟失
情況2：網(wǎng)絡(luò )延時(shí)，數據段推遲到達
情況3：數據段成功到達，應答因為1.2不能達到。
十四： TCP中，序列號和應答號有哪些作用?
從以上10,11,12中，很明顯的可以看到
依靠序列號重組數據段
依靠數據包消除網(wǎng)絡(luò )中的重復包
依靠序列號和應答號進(jìn)行差錯重傳，提高了TCP的可靠性
十六：為什么需要窗口技術(shù)?
前面我們已經(jīng)說(shuō)了，TCP的可靠性，是通過(guò)預期確認來(lái)實(shí)現的。即發(fā)送方發(fā)送一個(gè)數據段后，需要得到對方的確認后，才會(huì )發(fā)送下一個(gè)數據段。
因此，假設一個(gè)數據段大小為64KB(IP包最大值)，一次發(fā)送和確認需要的時(shí)間為500MS，則，1S內，只能傳送128KB的數據，如果帶寬為1M，顯然很浪費帶寬。為了充分利用帶寬，我們使用窗口技術(shù)�；瑒�(dòng)窗口允許發(fā)送方在收到接收方的確認之前發(fā)送多個(gè)數據段。(窗口大小決定了在收到確認前可以發(fā)送的數據段數量)
十七：如何實(shí)現流量控制?
窗口數決定了當前傳輸的最大流量。當我們在傳輸過(guò)程中，通信雙方可以根據網(wǎng)絡(luò )條件動(dòng)態(tài)協(xié)商窗口大小，調整窗口大小時(shí)，即可實(shí)現流量控制。(在TCP的每個(gè)確認中，除了ACK外，還包括一個(gè)窗口通知)
十八：UDP的開(kāi)銷(xiāo)很小，具體是指什么?
1.因為UDP是無(wú)連接的。在傳輸數據之前，不需要進(jìn)行復雜的三次握手來(lái)建立連接。
2.在傳輸數據時(shí)，沒(méi)有協(xié)議間通信流量(確認信號)，也不需要浪費不必要的處理時(shí)間(接收確認信號再發(fā)一下)。
3;傳輸結束后，也不用再用改進(jìn)的三次握手來(lái)端口連接。
十九：UDP數據包、TCP數據包大小如何確認?
無(wú)論TCP還是UDP數據包，都需要交給Internet層封裝為IP包，而一個(gè)IP包，包頭中的長(cháng)度位為16位，所以IP包最大為2的16方，即65535(64KB還需要減去各種包頭長(cháng)度)。
TCP因為面向流，且可以憑借序列號對大文件進(jìn)行分段和重組，因此，TCP可以用來(lái)傳輸較大的文件。而UDP，如果要傳輸大于64KB的數據，則需要自己在應用層進(jìn)行差錯控制。
為了提高傳輸效率和減少網(wǎng)絡(luò )通信量(協(xié)議間的通信)，TCP也會(huì )一次傳輸足夠多的數據。
因為MTU的存在，TCP包和UDP包不是越大越好。(在路由中分包，在接收端重組，加大路由與接收端負擔，增大丟包概率。分組丟失，整個(gè)數據包重傳。)
二十：UDP適用哪些環(huán)境?TCP適用哪些環(huán)境?
適合UDP的環(huán)境：
1.在高效可靠的網(wǎng)絡(luò )環(huán)境中(不需要考慮網(wǎng)絡(luò )不好導致的丟包、亂序、延時(shí)、重復等問(wèn)題)，因為UDP是無(wú)連接的服務(wù)，不用消耗不必要的網(wǎng)絡(luò )資源(TCP中的協(xié)議間通信)和處理時(shí)間(預期確認需要的時(shí)間)，從而效率要高的多。
2.在輕權通信中，當需要傳輸的數據量很小(可以裝在一個(gè)IP數據包內)時(shí)。如果我們使用TCP協(xié)議，那么，先建立連接，一共需要發(fā)送3個(gè)IP數據包，然后數據傳輸，1個(gè)IP數據包，產(chǎn)生一個(gè)確認信號的IP包，然后關(guān)閉連接，需要傳輸5個(gè)IP數據包。使用TCP協(xié)議IP包的利用率為1/10。而使用UDP，只需要發(fā)送一個(gè)IP數據包。哪怕丟包(服務(wù)不成功)，也可重新申請服務(wù)(重傳)。
| 注：而且無(wú)論UDP還是TCP，傳輸的都是IP數據包。當網(wǎng)絡(luò )環(huán)境不好導致丟包時(shí)，無(wú)論TCP還是UDP都會(huì )丟包，這是沒(méi)有區別的。（如果考慮發(fā)送丟包，那么TCP效率更低），只是使用TCP，當連接建立成功后，TCP程序會(huì )進(jìn)行可靠性控制。 |
UDP很適合這種客戶(hù)機向服務(wù)器傳送簡(jiǎn)單服務(wù)請求的環(huán)境。此類(lèi)應用層協(xié)議包括TFTP , SNMP , DNS ,DHCP等。
3.在對實(shí)時(shí)性要求很強的通信中：在諸如實(shí)時(shí)視頻直播等對實(shí)時(shí)性要求很高的環(huán)境中，從而允許一定量的丟包的情況下(直播比賽，前面丟失的包，重傳出來(lái)已經(jīng)意義不大了)，UDP更適合。(可以根據具體需要通過(guò)應用層協(xié)議提供可靠性，不用像TCP那么嚴格。)
適合TCP協(xié)議的環(huán)境：
當網(wǎng)絡(luò )硬件失效或者負擔太重時(shí)，數據包可能就會(huì )產(chǎn)生丟失、重復、延時(shí)、亂序的現象。這些都會(huì )導致我們的通信不正常的時(shí)候。如果讓?xiě)贸绦騺?lái)?yè)摬铄e控制的工作，無(wú)疑將給程序員帶來(lái)許多復雜的工作，于是，我們使用獨立的通信協(xié)議來(lái)保證通信的可靠性是非常必要的。
【TCP/IP傳輸層】相關(guān)文章：
OSI七層與TCP/IP五層網(wǎng)絡(luò )架構詳解09-07
TCP/IP協(xié)議是什么06-18
對TCP/IP網(wǎng)絡(luò )協(xié)議的深入淺出歸納10-16
查找本地IP/網(wǎng)絡(luò )IP/對方IP地址圖文教程07-17
TCP的可靠性10-30
IP雷達使用教程09-03
TCP與UDP協(xié)議有什么不同09-16