環境介紹：
1、用戶端通路FTP伺服器進行下載下傳檔案，由于FTP是基于TCP協定進行工作的，是以用戶端在通路FTP伺服器時必然會進行建立TCP連接配接。
2、通過在交換機上對任意端口進行抓包，來分析TCP的傳輸資料時封包互動的過程，以及TCP的視窗機制凸顯的現象。
一、TCP資料封包互動
為什麼說TCP協定可靠的？
其中一項就是因為TCP協定在傳輸資料的過程對，會對接收到的TCP資料進行一個确認。
當對方發來一個Seq封包序号2、并承載100Byte的TCP資料，我成功收到且FCS檢查無誤之後，回複Flags-ACK置位1、ack序号=(收到的Seq+收到的資料大小)=4+100=104TCP封包進行确認。對方收到Seq為104的封包，就知道了我成功接收到了100Byte的資料。
簡述TCP資料封包互動過程：
- 用戶端請求下載下傳檔案之後，建立起傳輸的TCP連接配接。
- 連接配接建立之後，伺服器告知用戶端：請求檔案的大小以及發送的方式、編碼等。随後基于TCP連接配接發送FTP-DATA。 FTP-DATA為什麼是兩個包？因為在TCP建立的時候知道MSS=1460(傳輸最大檔案大小限制)，而下載下傳的index.html檔案大小為1649Byte，需要分成1460+189兩個FTP-DATA包進行傳輸
- 收到FTP-DATA之後，用戶端向伺服器回複ACK确認：ack=1651。 FTP-DATA(1)封包資訊：seq=1，ack=1，Len=1460FTP-DATA(2)封包資訊：seq=1461，ack=1，len=189兩個包都收到之後，檢查無誤，最後一個包的seq=1461、資料大小lene=189，是以回複的ACK封包中，ack序号=1461+189=1651.
抓包資訊：
（1）總體資訊
（2）FTP-DATA(1)
（3）FTP-DATA(2)
（4）FTP回複的ACK
華為官網教材截圖（HCIA-02 網絡參考模型）：
為什麼PC1所發的Ack字段沒有增長？
TCP成功建立之後，回複的TCP封包ackp字段隻會将收到的封包中seq字段與Data字段大小進行相加成為ack字段的新值。
即：ack=seq+data，如果收到的TCP封包中data(載荷)=0，即ack=seq，也就是圖中ack=seq=b+1的原因。
二、TCP視窗機制
TCP通過滑動視窗機制來控制資料的傳輸速率，保障資料傳輸時不會因為其中一端傳輸太快導緻資料丢失。
在TCP三向交握建立連接配接時，雙方都會通過Window（win）字段告訴對方本端最大能夠接受的位元組數（也就是緩沖區大小，機關Byte）。
TCP視窗機制如何進行工作的？
- 連接配接建立成功之後，發送方會根據接受方宣告的Window大小發送相應位元組數的資料。
- 接受方 接受到資料之後會放在緩沖區内，等待上層應用來取走緩沖的資料。若資料被上層取走，則相應的緩沖空間将被釋放。
- 接收方 根據自身的緩存空間大小，在回複TCP封包時更新視窗大小( Window )。
- 發送方 根據接收方回複的視窗大小，實時更改發送相應數量的資料。
TCP視窗機制對資料互動有什麼影響？
- 教程中常常看到的資料互動都是發一個資料包就回複一個确認，這種主要為了讓我們好了解，現實中如果需要實作這種一個資料封包就回複一個确認，就需要使用到TCP封包中的PSH字段。
- 如果網絡中都是這樣一包一回複，大量不必要的資料封包在網絡中傳輸，易造成網絡負載較重，使得傳輸效率降低。
- 視窗機制有個特點就是不斷的接收資料放置在緩沖區中，直到緩沖區被占用滿或者遇到PSH置位的TCP封包，才會進行資料轉發，以及回複ACK進行資料确認。這樣統一的回複有效減少了大量确認資料在網絡中傳輸。
TCP中的PSH字段作用？
- 通過TCP報頭中的PSH字段 控制伺服器緩沖區内的資料立即傳送出去。
- 什麼時候用到PSH字段呢？
- 對于需要緊急處理的指令資料，需要快速的進行轉發處理，就需要應用到PSH。
- 如：資料互動執行個體中的用戶端下載下傳index.html檔案，需要緊急執行下載下傳，如果等待send buffer（緩沖區）滿了再轉發，用戶端看來就是等了很久才開始進行下載下傳/傳輸檔案。
華為官網教材截圖（HCIA-02 網絡參考模型）：
注：圖中的win=3，表示可接收的資料包為3個。在實際環境中，該字段通常表示目前可接受處理的資料大小，機關Byte。
為什麼PC1所發封包的Win字段沒有變化？
因為win表示的是本端目前所能接收的資料視窗大小，即目前可處理的資料量大小。自己發送的資料并不會占用win視窗量。
為什麼PC1所發封包的Win字段沒有變化？
因為win表示的是本端目前所能接收的資料視窗大小，即目前可處理的資料量大小。自己發送的資料并不會占用win視窗量。