本章討論TCP/IP體系中運輸層最重要的兩種協(xié)議：UDP和TCP。必須弄清TCP的各種機制（如面向連接的可靠服務、流量控制、擁塞控制等），以及TCP連接管理和狀態(tài)圖的概念。
一、運輸層協(xié)議概述
1.進程之間的通信
IP協(xié)議是把分組送到目的主機，但這個分組還停留在主機的網(wǎng)絡層而沒有交付給主機中的應用進程。從運輸層角度看，通信的真正端點并不是主機而是主機中的進程。
復用（multiplexing）——發(fā)送方不同的應用進程都可以使用同一個運輸層協(xié)議傳送數(shù)據(jù)（當然需要加上適當?shù)氖撞浚?/p>
分用（demultiplexing）——接收方的運輸層在剝?nèi)笪牡氖撞亢竽軌虬堰@些數(shù)據(jù)正確交付到目的應用進程。
運輸層提供應用進程間的邏輯通信：指運輸層之間的通信好像是沿水平方向傳送數(shù)據(jù)，但事實上這兩個運輸層之間并沒有一條水平方向的物理連接。要傳送的數(shù)據(jù)是沿著圖中的虛線方向（經(jīng)過多個層次）傳送的。
運輸層還要對收到的報文進行差錯檢測。在網(wǎng)絡層，IP數(shù)據(jù)報首部中的檢驗和字段，只檢驗首部是否出現(xiàn)差錯而不檢查數(shù)據(jù)部分。
兩種不同協(xié)議：①面向連接的TCP：盡管下面的網(wǎng)絡是不可靠的（只提供盡最大努力服務），但這種邏輯通信信道就相當于一條全雙工的可靠信道。②無連接的UDP協(xié)議：仍是不可靠信道。
2.運輸層的兩個主要協(xié)議
（1）用戶數(shù)據(jù)報協(xié)議UDP（user datagram protocol）
在傳送數(shù)據(jù)之前不需要先建立連接，遠地主機的運輸層在收到UDP報文后，不需要給出任何確認。不提供可靠支付。
（2）傳輸控制協(xié)議TCP（transmission control protocol）
提供可靠的、面向連接的服務。在傳送數(shù)據(jù)之前必須先建立連接，數(shù)據(jù)傳送后要釋放連接。不提供廣播或多播服務。
按OSI術(shù)語，兩個對等運輸實體在通信時傳送的數(shù)據(jù)單位叫作運輸協(xié)議數(shù)據(jù)單元TPDU（transport protocol data unit）。但在TCP/IP體系中，則根據(jù)所使用的協(xié)議是TCP或UDP，分別稱之為TCP報文段或UDP用戶數(shù)據(jù)報。
3.運輸層的端口
Ⅰ、運輸層的復用——應用層所有的應用進程都可以通過運輸層再傳到IP層
運輸層的分用——運輸層從IP層收到數(shù)據(jù)后必須交付給指明的應用進程
Ⅱ、為什么要在運輸層使用協(xié)議端口號（protocol port number，或端口）？
給應用層的每個應用進程賦予一個非常明確的標志很重要。在單個計算機中的進程是用進程標識符來標志的。但在因特網(wǎng)環(huán)境下，就不行了，因為在因特網(wǎng)上使用的計算機的操作系統(tǒng)種類很多，而不同的操作系統(tǒng)又使用不同格式的進程標志符。為了使運行不同操作系統(tǒng)的計算機的應用進程能夠互相通信，就必須用統(tǒng)一的方法（而這種方法必須與特定操作系統(tǒng)無關(guān)）對TCP/IP體系的應用進程進行標志。
但是，把一個特定機器上運行的特定進程指明為因特網(wǎng)上通信最后的終點還是不可行的。這是因為進程的創(chuàng)建和撤銷都是動態(tài)的，通信的一方幾乎無法識別對方機器上的進程。另外，我們往往需要利用目的主機提供的功能來識別終點，而不需要知道具體實現(xiàn)這個功能的進程是哪一個。
解決這個問題的方法就是在運輸層使用協(xié)議端口號。雖然通信的終點是應用進程，但我們只要把要傳送的報文交到目的主機的某一個合適的目的端口，剩下的工作（即最后交付給目的進程）就由TCP來完成。
Ⅲ、端口認知
這種在協(xié)議棧層間抽象的協(xié)議端口是軟件端口，軟件端口是應用層的各種協(xié)議進程與運輸實體進行層間交互的一種地址。
路由器或交換機上的硬件端口是不同硬件設備進行交互的接口。
Ⅳ、端口號
只具有本地意義，只是為了標志本計算機應用層中的各個進程和運輸層交互時的層間接口。在因特網(wǎng)不同計算機中，相同的端口號是沒有關(guān)聯(lián)的。
兩計算機中的進程通信時，不僅需要知道對方的IP地址（為了找到對方的計算機），還要知道對方的端口號（為了找到對方計算機中的應用進程）。因特網(wǎng)上的計算機通信采用客戶—服務器方式，于是運輸層的端口號可分為：
（1）服務器端使用的端口號
①熟知端口號（well-known port number）或系統(tǒng)端口號
IANA把這些端口號指派給了TCP/IP最重要的一些應用程序，讓所有的客戶都知道。當一種新的應用程序出現(xiàn)后，IANA必須為它指派一個熟知端口，否則因特網(wǎng)上的其他應用進程就無法和它進行通信。
②登記端口號
是為沒有熟知端口號的應用程序使用的，使用這類端口號必須在IANA按照規(guī)定的手續(xù)登記，以防止重復。
（2）客戶端使用的端口號（短暫端口號）
僅在客戶進程運行時才動態(tài)選擇，留給客戶進程選擇時暫時使用。當服務器進程收到客戶進程的報文時，就知道了客戶進程所使用的端口號，因而可以把數(shù)據(jù)發(fā)送給客戶進程。通信結(jié)束后，剛才已使用過的客戶端口號就不復存在。這個端口號就可以供其他客戶進程以后使用。
二、用戶數(shù)據(jù)報協(xié)議UDP
1.UDP概述
只在IP的數(shù)據(jù)服務之上增加了很少一點功能，這就是復用和分用、差錯檢測。
主要特點：（1）無連接的。發(fā)送數(shù)據(jù)之前不需要建立連接（發(fā)送完可釋放）（2）使用盡最大努力交付，即不保證可靠交付，主機不需要維持復雜的連接狀態(tài)表。（3）面向報文的。UDP一次交付一個完整的報文，因此應用程序必須選擇合適大小的報文。若報文太長，UDP把它交給IP層后，IP層在傳送時可能要進行分片，這會降低IP層的效率。反之，若報文太短，UDP把它交給IP層后，會使IP層的首部的相對長度太大，這也降低了IP層的效率。
（4）沒有堵塞控制
網(wǎng)絡出現(xiàn)的堵塞不會使源主機的發(fā)送速率降低，這對某些實時應用很重要，比如實時視頻會議要求源主機以恒定的速率發(fā)送數(shù)據(jù)，并且允許在網(wǎng)絡發(fā)生堵塞時丟失一些數(shù)據(jù)，但卻不允許數(shù)據(jù)有太大的時延。
但當很多源主機同時向網(wǎng)絡發(fā)送高速率的實時視頻流時，網(wǎng)絡就有可能發(fā)生堵塞，結(jié)果大家都無法正常接收。還有些實時應用需要對它的不可靠傳輸進行適當?shù)母脑欤詼p少數(shù)據(jù)的丟失。
（5）支持一對一、一對多、多對一、多對多的交互通信
（6）首部開銷小，只有8個字節(jié)
2.UDP的首部格式
用戶數(shù)據(jù)報UDP有兩個字段：數(shù)據(jù)字段和首部字段。首部字段很簡單，只有8個字節(jié)，由四個字段組成，每個字段的長度都是兩個字節(jié)。各字段：
（1）源端口：源端口號，在需要對方回信時選用，不需要時可用全0。
（2）目的端口：目的端口號，這在終點交付報文時必須要使用到。
（3）長度：UDP用戶數(shù)據(jù)報的長度，其最小值是8（只有首部）。
（4）檢驗和：檢測UDP用戶數(shù)據(jù)報在傳輸中是否有差錯，有錯就丟棄。
當運輸層從IP層收到UDP數(shù)據(jù)報時，就根據(jù)首部中的目的端口，把UDP數(shù)據(jù)報通過相應的端口，上交最后的終點——應用進程。下圖是UDP基于端口的分用的示意圖。
如果接收方UDP發(fā)現(xiàn)收到的報文中的目的端口號不正確（即不存在對應于該端口號的應用進程），就丟棄該報文，并由ICMP發(fā)送“端口不可達”差錯報文給發(fā)送方。我們在上一章4.4.2節(jié)討論traceroute時，就是讓發(fā)送的UDP用戶數(shù)據(jù)報故意使用一個非法的UDP端口，結(jié)果ICMP就返回“端口不可達”差錯報文，因而達到了測試的目的。
檢驗和的計算方法：
（1）偽首部——12字節(jié)，它不是UDP用戶數(shù)據(jù)報真正的首部，只是用于計算檢驗和而臨時添加的，它既不向下傳送也不向上遞交。
（2）和IP數(shù)據(jù)報首部檢驗和的方法的不同——IP數(shù)據(jù)報的檢驗和只檢驗IP數(shù)據(jù)報的首部，而UDP的檢驗和是把首部和數(shù)據(jù)部分一起都檢驗。
（3）發(fā)送方——先把全零放入檢驗和字段，再把偽首部以及UDP用戶數(shù)據(jù)報看成是由許多16位的字串接起來。若UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分不是偶數(shù)個字節(jié)，則要填入一個全零字節(jié)（但此字節(jié)不發(fā)送）。然后按二進制反碼計算出這些16位字的和。將此和的二進制反碼寫入檢驗和字段后，就發(fā)送這樣的UDP用戶數(shù)據(jù)報。
（4）接收方——把收到的UDP用戶數(shù)據(jù)報連同偽首部（以及可能的填充全零字節(jié)）一起，按二進制反碼求這些16位字的和。當無差錯時結(jié)果應全1。否則就表明有差錯實現(xiàn)，接收方就丟棄這個UDP用戶數(shù)據(jù)報（也可以上交給應用層，但附上出現(xiàn)差錯的警告）。
（5）評價——檢錯能力不強，但簡單、處理起來較快。
偽首部的第3字段全是0，第4字段是IP首部中的協(xié)議字段的值。以前已講過，對于UDP，此協(xié)議字段值為17。第5字段是UDP用戶數(shù)據(jù)報的長度。因此，這樣的檢驗和，既檢查了UDP用戶數(shù)據(jù)報的源端口和目的端口號以及UDP用戶數(shù)據(jù)報的數(shù)據(jù)部分，又檢查了IP數(shù)據(jù)報的源IP地址和目的地址。
三、傳輸控制協(xié)議TCP概述
1.TCP最重要的特點
（1）是面向連接的運輸層協(xié)議：傳送數(shù)據(jù)完畢后，必須釋放已建立的TCP連接。
（2）每一條TCP連接只能有兩個端點（endpoint），每一條TCP連接只能是點對點的。
（3）提供可靠交付的服務——無差錯、不丟失、不重復、且按序到達。
（4）全雙工通信——TCP允許通信雙方的應用進程在任何時候都能發(fā)送數(shù)據(jù)，TCP連接的兩端都設有發(fā)送緩存和接收緩存，用來臨時存放雙向通信的數(shù)據(jù)。
（5）面向字節(jié)流
“流”是指流入到進程或從進程流出的字節(jié)序列。面向字節(jié)流的含義是：雖然應用程序和TCP的交互是一次一個數(shù)據(jù)塊（大小不等），但TCP把應用程序交下來的數(shù)據(jù)看成僅僅是一連串的無結(jié)構(gòu)的字節(jié)流。TCP并不知道所傳送的字節(jié)流的含義，它不保證接收方應用程序所收到的數(shù)據(jù)塊和發(fā)送方應用程序所發(fā)出的數(shù)據(jù)塊具有對應大小的關(guān)系（例如，發(fā)送方應用程序交給發(fā)送方的TCP共10個數(shù)據(jù)塊，但接收方的TCP可能只用了4個數(shù)據(jù)塊就把收到的字節(jié)流交付給了上層的應用程序）。但接收方應用程序收到的字節(jié)流必須和發(fā)送方應用程序發(fā)出的字節(jié)流完全一樣。當然，接收方的應用程序必須有能力識別收到的字節(jié)流，把它還原成有意義的應用層數(shù)據(jù)。
解釋上圖：TCP連接是一條虛連接而不是一條真正的物理連接。TCP報文段先要傳送到IP層，加上IP首部后，再傳送到數(shù)據(jù)鏈路層。再加上數(shù)據(jù)鏈路層的首部和尾部后，才離開主機發(fā)送到物理鏈路。
TCP和UDP在發(fā)送報文時采用的方式完全不同。TCP對應用程序一次把多長的報文發(fā)送到TCP的緩存中是不關(guān)心的。TCP根據(jù)對方給出的窗口值和當前網(wǎng)絡擁塞的程度來決定一個報文段應包含多少個字節(jié)（UDP發(fā)送的報文長度是應用進程給出的）。如果應用進程傳送到TCP緩存的數(shù)據(jù)塊太長，TCP就可以把它劃分短一些再傳送。如果應用進程一次只發(fā)來一個字節(jié)，TCP也可以等待積累有足夠多的字節(jié)后再構(gòu)成報文段發(fā)送出去。
2.TCP的連接
TCP把連接作為最基本的抽象，TCP的許多特性都與TCP是面向連接的這個基本特性有關(guān)。
每一條TCP連接有兩個端點，它不是主機、不是主機的IP地址、不是應用進程、不是運輸層的協(xié)議端口，而是套接字（是端口號拼接到IP地址即構(gòu)成了套接字）。套接字socket=（IP地址：端口號）
每一條TCP連接唯一地被通信兩端的兩個端點（即兩個套接字）所確定。即：
TCP連接：：={socket1，socket2}={（IP1：port1），（IP2：port2）}
TCP連接就是由協(xié)議軟件所提供的一種抽象，是應用進程之間建立的。TCP連接的端點是套接字，即（IP地址：端口號）。同一個IP地址可以有很多個不同的TCP連接，而同一個端口號也可以出現(xiàn)在多個不同的TCP連接中。
注意：socket有很多意思。
四、可靠傳輸?shù)墓ぷ髟?/h3>
TCP發(fā)送的報文段是交給IP層傳送的，但IP層只能提供盡最大努力服務，也就是說，TCP下面的網(wǎng)絡所提供的是不可靠傳輸。TCP必須采用適當?shù)拇胧┎拍苁沟脙蓚€運輸層之間的通信變得可靠。
理想傳輸條件有：①傳輸信道不產(chǎn)生差錯。②不管發(fā)送方以多快的速度發(fā)送數(shù)據(jù)，接收方總是來得及處理收到的數(shù)據(jù)。
在這樣的理想傳輸條件下，不需要采取任何措施就能實現(xiàn)可靠傳輸。達不到時，我們可以使用可靠傳輸協(xié)議。當出現(xiàn)差錯時讓發(fā)送方重傳出現(xiàn)差錯的數(shù)據(jù)，同時在接收方來不及處理收到的數(shù)據(jù)時，及時告訴發(fā)送方適當降低發(fā)送數(shù)據(jù)的速度。
1.停止等待協(xié)議
因為這里是討論可靠傳輸?shù)脑恚虼税褌魉偷臄?shù)據(jù)單元都稱為分組，而不考慮數(shù)據(jù)是在哪一層次上傳送的。“停止等待”就是每發(fā)送完一個分組就停止發(fā)送，等待對方的確認。在收到確認后再發(fā)送下一個分組。
Ⅰ、無差錯情況
A在收到了對M1的確認后，就再發(fā)送給下一個分組M2。
Ⅱ、出現(xiàn)差錯
B接收M1時檢測出了差錯，就丟棄M1，其他什么也不做（不通知A收到有差錯的分組），也可能是M1在傳輸過程中丟失了，這時B當然什么都不知道。在這兩種情況下，B都不會發(fā)送任何信息。可靠傳輸協(xié)議是這樣設計的：A只要超過了一段時間仍然沒有收到確認，就認為剛剛發(fā)送的分組丟失了，因而重傳前面發(fā)送過的分組。這就叫做超時重傳。
要實現(xiàn)超時重傳，就要在每發(fā)送完一個分組設置一個超時計時器。如果在超時計時器到期之前收到了對方的確認，就撤銷已設置的超時計時器。在a圖中，A為每一個已發(fā)送的分組都設置了一個超時計時器，但A只要在超時計時器到期之前收到了相應的確認，就撤銷該超時計時器。
注意：①A在發(fā)送完一個分組，必須暫時保留已發(fā)送的分組的副本（為發(fā)生超時重傳時使用）。只有在收到相應的確認后才能清除暫時保留的分組副本。
②分組和確認分組都必須進行編號。這樣才能明確是哪一個發(fā)送出去的分組收到了確認，而哪一個分組還沒有收到確認。
③超時計時器設置的重傳時間應當比數(shù)據(jù)在分組傳輸?shù)钠骄禃r間更長一些。如果重傳時間設定長了，通信效率就低；如果短了，產(chǎn)生不必要的重傳，浪費了網(wǎng)絡資源。設定準確的重傳時間是復雜的，因為已發(fā)送出的分組到底會經(jīng)過哪些網(wǎng)絡，以及時延，都是不確定因素。
Ⅲ、確認丟失和確認遲到
圖a：B收到重傳分組M1時，采取兩行動，一是丟棄這個重復的分組M1，不向上層支付；二是向A發(fā)送確認，不能認為已經(jīng)發(fā)送過確認就不再發(fā)送，因為A之所以重傳M1就表示A沒有收到對M1的確認。
圖b：確認遲到了，收到就丟棄。如果A不斷重傳分組但總是收不到確認，說明通信線路太差，不能進行通信。
使用上述的確認和重傳機制，我們就可以在不可靠的傳輸網(wǎng)絡上實現(xiàn)可靠的通信。像上述的這種可靠傳輸協(xié)議常稱為自動重傳請求ARQ（automatic repeat reQuest），意思是重傳的請求是自動進行的。接收方不需要請求發(fā)送方重傳某個出錯的分組。
Ⅳ、信道利用率
停止等待協(xié)議的優(yōu)點是簡單，但缺點是信道利用率太低。
假定A發(fā)送分組需要的時間是Td（=分組長度/數(shù)據(jù)率）；分組正確到達B后，B處理分組的時間可以忽略不計，同時立即發(fā)回確認；B發(fā)送確認分組需要時間Ta。如果A處理確認分組的時間也可以忽略不計，那么A在經(jīng)過時間（Td+RTT+Ta）后就可以再發(fā)送下一個分組，這里的RTT是往返時間。因為僅僅是在時間Td內(nèi)才用來送有用的數(shù)據(jù)（包括分組的首部），因此信道的利用率U可以用下式計算：
為了提高傳輸效率，發(fā)送方可以不使用低效率的停止等待協(xié)議，而是采用流水線傳輸。看下圖，它就是發(fā)送方可連續(xù)發(fā)送多個分組，不必每發(fā)完一個分組就停下來等待對方的確認。這樣可使信道上一直有數(shù)據(jù)不間斷地在傳送。顯然，這樣可獲得很高的信道利用率。
當使用流水線傳輸時，就要使用下面介紹的連續(xù)ARQ協(xié)議和滑動窗口協(xié)議（5.6節(jié)討論）。
2.連續(xù)ARQ協(xié)議
圖a表示發(fā)送方維持的發(fā)送窗口，它的意義是：位于發(fā)送窗口內(nèi)的5個分組都可以連續(xù)發(fā)送出去，而不需要等待對方的確認。這樣提高了信道利用率。
根據(jù)ARQ協(xié)議規(guī)定，發(fā)送方每收到一個確認，就把發(fā)送窗口向前滑動一個分組的位置。圖b表示發(fā)送方收到了對第一個分組的確認，于是把發(fā)送窗口向前移動一個分組的位置。如果原來已經(jīng)發(fā)送了前5個分組，那么現(xiàn)在就可以發(fā)送窗口內(nèi)的第6個分組了。
接收方一般都是采用累積確認的方式，即在收到幾個分組后，對按序到達的最后一個分組發(fā)送確認。這樣就表示：到這個分組為止的所有分組都已正確收到了。
累積確認優(yōu)點：容易實現(xiàn)，及時確認丟失也不必重傳。缺點：不能向發(fā)送方反映出接收方已經(jīng)正確收到的所有分組的信息。
例如，如果發(fā)送方發(fā)送了前5個分組，而中間的第3個分組丟失了。這時接收方只能對前兩個分組發(fā)送確認。發(fā)送方無法知道后面三個分組的下落，而只好把后面的三個分組都再重傳一次。這就叫作Go-back-N（回退N），表示需要再退回來重傳已發(fā)送過的N個分組。可見，當通信線路質(zhì)量不好時，連續(xù)ARQ協(xié)議會帶來負面的影響。
五、TCP報文段的首部格式
TCP雖然是面向字節(jié)流的，但TCP傳送的數(shù)據(jù)單元卻是報文段。一個TCP報文段分為首部和數(shù)據(jù)兩部分，而TCP的全部功能都體現(xiàn)在它首部中各字段的作用。因此，弄清首部各字段作用才能弄清它的工作原理。
前20字節(jié)固定，后4N（N是整數(shù)）字節(jié)是根據(jù)需要而增加的選項。
（1）源端口和目的端口：TCP的分用是通過端口實現(xiàn)的。
（2）序號
序號范圍[0,2^32-1]，序號增加到最大值時，下一個序號就又回到0。TCP是面向字節(jié)流的，在一個TCP連接中傳送的字節(jié)流中的每一個字節(jié)都按順序編號，整個要傳送的字節(jié)流的起始序號必須在連接建立時設置。首部中的序號字段（也叫作報文段序號）值則指的是本報文段所發(fā)送的數(shù)據(jù)的第一個字節(jié)的序號。
（3）確認號：是期望收到對方下一個報文段的第一個數(shù)據(jù)字節(jié)的序號。若確認號=N，則表明：到序號N-1為止的所有數(shù)據(jù)都已正確收到。
（5）數(shù)據(jù)偏移：占4位，指出TCP報文段的數(shù)據(jù)起始處距離TCP報文段的起始處有多遠。這個字段實際上指出TCP報文段的首部長度。（首部中還有長度不確定的選項字段）
（6）保留：占6位，保留為今后用，但目前設置為0。
（7）緊急URG
當URG置1時，發(fā)送應用進程就告訴發(fā)送方的TCP有緊急數(shù)據(jù)要傳送。于是發(fā)送方TCP就把緊急數(shù)據(jù)插入到本報文段數(shù)據(jù)的最前面，而在緊急數(shù)據(jù)后面的數(shù)據(jù)仍是普通數(shù)據(jù)，這時要與首部中緊急指針（urgent pointer）字段配合使用。
（8）確認ACK（ACKnowlegment）
僅當ACK置1時，確認號字段才有效。為0時無效。TCP規(guī)定，在連接建立后所有傳送的報文段都必須把ACK置1。
（9）推送PSH（push）
當兩個應用進程進行交互式的通信時，有時在一端的應用進程希望在鍵入一個命令后立即就能夠收到對方的響應。在這種情況下，TCP就可以使用推送（push）操作。這時，發(fā)送方TCP把PSH置1，并立即創(chuàng)建一個報文段發(fā)送出去。接收方TCP收到PSH=1的報文段，就盡快地交付給接收應用進程，而不再等到整個緩存都填滿了后再向上交付。得少用。
（10）復位RST（ReSeT）
為1時表明TCP連接中出現(xiàn)嚴重差錯（如主機崩潰），必須釋放連接，然后再重新建立運輸連接。RST置1還用來拒絕一個非法的報文段或拒絕打開一個連接。也成為重建位或重置位。
（11）同步SYN（SYNchronization）
在連接建立時用來同步序號。當SYN=1而ACK=0時，表明這是一個連接請求報文段。對方若同意建立連接，則應在響應的報文段中使SYN=1和ACK=1。因此，SYN置1就表示這是一個連接請求或連接接受報文。
（12）終止FIN（FINis）
用來釋放一個連接。為1時表明此報文段的發(fā)送方的數(shù)據(jù)已發(fā)送完畢，并要求釋放運輸連接。
（13）窗口
窗口值是[0,2^16-1]之間的整數(shù)。明確指出了現(xiàn)在允許對方發(fā)送的數(shù)據(jù)量，窗口值作為接收方讓發(fā)送方設置其發(fā)送窗口的依據(jù)。有這個限制是因為接收方的數(shù)據(jù)緩存空間是有限的。
（14）檢驗和
檢驗和字段檢驗的范圍包括首部和數(shù)據(jù)這兩部分。和UDP用戶數(shù)據(jù)報一樣，在計算檢驗和時，要在TCP報文段的前面加上12字節(jié)的偽首部。偽首部的格式與UDP用戶數(shù)據(jù)報的偽首部一樣。但應把偽首部第4個字段中的17改為6（TCP的協(xié)議號是6），把第5字段中的UDP長度改為TCP長度。接收方收到此報文段后，仍要加上這個偽首部來計算檢驗和。若使用IPv6，則相應的偽首部也要改變。
（15）緊急指針
僅在URG=1時才有意義，指出本報文段中的緊急數(shù)據(jù)的字節(jié)數(shù)（緊急數(shù)據(jù)結(jié)束后就是普通數(shù)據(jù)）。當所有緊急數(shù)據(jù)處理完時，TCP就告訴應用程序恢復到正常操作。即使窗口為零時也可以發(fā)送緊急數(shù)據(jù)。
（16）選項
長度可變，最長可達40字節(jié)。沒有使用選項時，TCP首部長度是20字節(jié)。有以下幾種：
①最大報文段長度MSS（maximum segment size）
理解——它是每一個TCP報文段中的數(shù)據(jù)字段的最大長度。數(shù)據(jù)字段加上TCP首部才等于整個的TCP報文段。所以MSS并不是整個TCP報文段的最大長度，而是“TCP報文段長度減去TCP首部長度”。
出現(xiàn)緣由——并不是考慮接收方的接收緩存可能放不下TCP報文段中的數(shù)據(jù)。實際上，MSS與接收窗口值沒有關(guān)系。我們知道，TCP報文段的數(shù)據(jù)部分，至少加上40字節(jié)的首部（TCP首部20字節(jié)和IP首部20字節(jié)，這里都還沒有考慮首部中的選項部分），才能組裝成一個IP數(shù)據(jù)報。MISS長度小時，網(wǎng)絡的利用率低。長度大時，IP層傳輸時就有可能要分解成多個短數(shù)據(jù)報片，在終點要把收到的各個短數(shù)據(jù)報片裝配成原來的TCP報文段。當傳輸出錯時要重傳，這些使開銷增大。
因此，MSS應盡可能大些，只要在IP層傳輸時不需要再分片就行。而IP數(shù)據(jù)報所經(jīng)歷的路徑是動態(tài)變化的，因此這條路徑不用分片下條路徑可能要分片，于是最佳MSS難確定。在連接建立過程中，雙方都把自己能夠支持的MSS寫入這一字段，以后就按照這個數(shù)值傳送數(shù)據(jù)，兩個傳送方向可以有不同的MSS值。若主機未填寫這一項，則MSS的默認值是536字節(jié)長。因此，所有在因特網(wǎng)上的主機都應能接受的報文段長度是536+20（固定首部長度）=556字節(jié)。
②窗口擴大選項
為了擴大窗口。占3字節(jié)，其中有一個字節(jié)表示移位值S。新的窗口值等于TCP首部中的窗口數(shù)從16增大到（16+S），這相當于把窗口值向左移動S位后獲得實際的窗口大小。移位值允許使用的最大值是14，相當于窗口最大值增大到2^（16+14）-1。
窗口擴大選項可以在雙方初始建立TCP連接時進行協(xié)商。如果連接的某一端實現(xiàn)了窗口擴大，當它不再需要擴大其窗口時，可發(fā)送S=0的選項，使窗口大小回到16。
③時間戳選項
占10字節(jié)，最主要的字段時間戳字段（4字節(jié)）和時間戳回送回答字段（4字節(jié)）。功能：一是用來計算往返時間RTT。發(fā)送方在發(fā)送報文段時把當前時鐘的時間值放入時間戳字段，接收方在確認該報文段時把時間戳字段值復制到時間戳回送回答字段。因此，發(fā)送方在收到確認報文后，可以準確計算出RTT來。二是處理TCP序號超過2^32的情況，這又稱為防止序號繞回PAWS（protect against wrapped sequence nambers），可以使接收方能夠把新的報文段和遲到很久的報文段區(qū)分開。
④選擇確認選項
5.6.3節(jié)介紹
