本節書摘來自異步社群《wireshark資料包分析實戰（第2版）》一書中的第6章6.3節傳輸控制協定，作者【美】chris sanders,更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。
6.3 傳輸控制協定
傳輸控制協定（transmission control protocol, tcp）的最終目的是為資料提供可靠的端到端傳輸。tcp在rfc793中定義，在osi模型中的第4層工作。它能夠處理資料的順序和錯誤恢複，并且最終保證資料能夠到達其應到達的地方。很多普遍使用的應用層協定都依賴于tcp和ip将資料包傳輸到其最終目的地。
6.3.1 tcp頭
tcp提供了許多功能，并且反映在了其頭部的複雜性上面。如圖6-16所示，以下是tcp頭的域。
源端口（source port）：用來傳輸資料包的端口。
目的端口（destination port）：資料包将要被發送到的端口。
序号（sequence number）：這個數字用來表示一個tcp片段。這個域用來保證資料流中的部分沒有缺失。
确認号（acknowledgment number）：這個數字是通信中希望從另一個裝置得到的下一個資料包的序号。
标記（flags）：urg、ack、psh、rst、syn和fin标記都是用來表示所傳輸的tcp資料包的類型。
視窗大小（window size）：tcp接收者緩沖的位元組大小。
校驗和（checksum）：用來保證tcp頭和資料的内容在抵達目的地時的完整性。
緊急指針（urgent pointer）：如果設定了urg位，這個域将被檢查作為額外的指令，告訴cpu從資料包的哪裡開始讀取資料。
選項（options）：各種可選的域，可以在tcp資料包中進行指定。
6.3.2 tcp端口
所有tcp通信都會使用源端口和目的端口，而這些可以在每個tcp頭中找到。端口就像是老式電話總機上的插口。一個總機操作員會監視着一個面闆上的訓示燈和插頭，當訓示燈亮起的時候，他就會連接配接這個呼叫者，問她想要和誰通話，然後插一根電纜将她和她的目的位置連接配接起來。每次呼叫都需要有一個源端口（呼叫者）和一個目的端口（接收者）。tcp端口大概就是這樣工作的。
為了能夠将資料傳輸到遠端伺服器或裝置的特定應用中去，tcp資料包必須知道遠端服務所監聽的端口。如果你想要試着連接配接一個不同于所設定的端口，那麼這個通信就會失敗。
這個序列中的源端口并不十分重要，是以可以随機選擇。遠端伺服器也可以很簡單地從發送過來的原始資料包中得到這個端口（如圖6-17所示）。
在使用tcp進行通信的時候，我們有65535個端口可供使用，并通常将這些端口分成兩個部分。
1～1023是标準端口組（忽略掉被預留的0），特定服務會用到這些通常位于标準端口分組中的标準端口。
1024～65535是臨時端口組（盡管一些作業系統對此有着不同的定義），當一個服務想在任意時間使用端口進行通信的時候，現代作業系統都會随機地選擇一個源端口，讓這個通信使用唯一源端口。這些源端口通常就位于臨時端口組。
讓我們打開檔案tcp_ports.pcap，看一些不同的tcp資料包，并識别出它們所使用的端口号。在這個檔案中，我們會看到一個用戶端在浏覽兩個網站時産生的http通信。正如前面所提到的http使用tcp進行通信，是以這将是一個非常典型的tcp流量案例。
在這個檔案中的第一個資料包中（如圖6-18所示），一開始的兩個值代表着這個資料包的源端口和目的端口。這個資料包從172.16.16.128發往212.58.226.142，它的源端口是屬于臨時端口組的2826圖示1（需要記住的是源端口是由作業系統随機選取的，盡管它們可能在随機選擇的過程中會選擇遞增政策）。目的端口是一個标準端口，80端口。這個标準端口正是提供給使用http的web伺服器的。
你可能會注意到wireshark将這些端口打上了slc-systemlog（2826）和http（80）的标簽。wireshark會維護一個端口的清單，并記錄它們最普遍的應用。盡管清單還是以标準端口為主，但很多臨時端口也關聯着常用的服務。這些端口的标簽可能會讓人迷惑，是以一般來說最好通過關閉傳輸名字解析來禁用它。選擇edit -> preference -> name resolution，然後取消勾選enable transport name resolution就可以将其禁用了。如果你希望保留這個功能但希望改變wireshark對每一個端口的識别，你可以通過改變wireshark程式目錄下的services檔案。這個檔案是根據網際網路數字配置設定機構（internet assigned numbers authority, iana）的通用端口清單編寫的。
第二個資料包是由212.58.226.142發往172.16.16.128的（如圖6-19所示）。除了ip位址之外，源端口和目的端口也同樣有所改變。
所有基于tcp的通信都以相同的方式工作：選擇一個随機的源端口與一個已知的目的端口進行通信。在發出初始資料包之後，遠端裝置就會與源裝置使用建立起的端口進行通信。
在這個捕獲檔案中還有另外一個通信流，你可以試着找出它通信時使用的端口。
注意
6.3.3 tcp的三次握手
所有基于tcp的通信都需要以兩台主機的握手開始。這個握手過程主要希望能達到以下不同的目的。
保證源主機确定目的主機線上，并且可以進行通信。
讓源主機檢查它是否正在監聽試圖去連接配接的端口。
允許源主機向接收者發送它的起始序列号，使得兩台主機可以将資料包流保持有序。
tcp握手分為3個步驟，如圖6-20所示。在第一步中，主動發起通信的裝置（主機a）向目标（主機b）發送了一個tcp資料包。這個初始資料包除了底層協定頭之外不包含任何資料。這個資料包的tcp頭設定了syn标志，并包含了在通信過程中會用到的初始序列号和最大分段大小（mss）。主機b對于這個資料包回複了一個類似于設定了syn和ack标志以及包含了它初始序列号的資料包。最後，主機a向主機b發送最後一個僅設定了ack标志的資料包。在這個過程完成之後，雙方裝置應該已經具有了開始正常通信所需的資訊。
tcp資料包在稱呼上通常會被其所設定的标志所代表。比如，對于設定了syn标志的tcp資料包，我們将會簡稱其為syn包。是以tcp握手過程中使用的資料包會被稱為syn包、syn/ack包和ack包。
打開tcp_handshake.pcap，可以更實際地看到這個過程。wireshark為了分析将簡便，引入了一個特性，可以将tcp資料包的序列号替換為相對值。但在這裡，我們将這個功能關閉，以便于能看到實際的序列号值。選擇edit -> preferences，展開protocols并選擇tcp，然後取消勾選relative sequence numbers and window scaling框，并單擊ok就可以禁用了。
這個捕獲中的第一個資料包是我們的初始syn資料包（如圖6-21所示）。這個資料包從172.16.16.128的2826端口發往212.58.226.142的80端口。我們可以看到這裡傳輸的序列号是3691127924圖示1。
握手中第二個資料包是從212.58.226.142發出的syn/ack響應（如圖6-22所示）。這個資料包也包含着這台主機的初始序列号（233779340）圖示1，以及一個确認号（2691127925）圖示２。這個确認号比之前的那個資料包序列号大1，是因為這個域是用來表示主機所期望得到的下一個序列号的值。
最後的資料包是從172.16.16.128（如圖6-23所示）發出的ack資料包。這個資料包正如所期望的那樣，包含着之前資料包确認号域所定義的序列号3691127925圖示1。
握手伴随着每次tcp的通信序列。當在一個繁忙的捕獲檔案中搜尋通信序列的開始時，syn、syn/ack、ack的序列是一個很好的标志。
6.3.4 tcp終止
所有的問候最終都會有一句再見，在tcp中，每次握手後也會有終止。tcp終止用來在兩台裝置完成通信後正常地結束連接配接。這個過程包含4個資料包，并且用一個fin标志來表明連接配接的終結。
在一個終止序列中，主機a通過發送一個設定了fin和ack标志的tcp資料包，告訴主機b通信的完成。主機b以一個ack資料包響應，并傳輸自己的fin/ack資料包。主機a響應一個ack資料包，然後結束通信過程。這個過程如圖6-24所示。
打開檔案tcp_teardown.pcap可以在wireshark中看到這個過程。在序列的第一個資料包（如圖6-25所示），你可以看到位于67.228.110.120的裝置通過發送有着fin和ack标志的資料包圖示1來開始終止過程。
在這個資料包被發出去之後，172.16.16.128使用了一個ack資料包進行響應來确認第一個資料包的接收，然後發送了一個fin/ack資料包。整個過程在67.228.110.120發送了最終的ack之後結束。這時，這兩個裝置的通信便已經結束，如果想要再次開始通信就必須完成新的tcp握手。
6.3.5 tcp重置
在理想情況中，每一個連接配接都會以tcp終止來正常地結束。但在現實中，連接配接經常會突然斷掉。舉例來說，這可能由于一個潛在的攻擊者正在進行端口掃描，或者僅僅是主機配置錯誤。在這些情況下，就需要使用設定了rst标志的tcp資料包。rst标志用來指出連接配接被異常中止或拒絕連接配接請求。
檔案tcp_refuseconnection.pcap給出了一個包含有rst資料包網絡流量的例子。這個檔案中的第一個資料包發自192.168.100.138，其嘗試與192.168.100.1的80端口進行通信。這個主機并不知道192.168.100.1并沒有在監聽80端口，因為那是一個思科路由器，并且沒有配置web接口，也就是說，并沒有服務監聽80端口的連接配接。為了響應這個連接配接請求，192.168.100.1向192.168.100.138發送了一個資料包，告訴它其對80端口的通信無效。圖6-26中展示了在第二個資料包的tcp頭中這個連接配接嘗試突然終止的情況。rst資料包除了包含rst和ack标志圖示1外，沒有任何其他的東西，之後也并沒有額外的通信。
如本例所示，rst資料包可以在通信序列的開始或者在主機通信的過程中，終止通信。