tcp上傳文件時的ack變化？

12-28

在一個tcp連接中，如果僅僅是客戶端一方在一直上傳文件，而且另一方的伺服器接收到包以後會發送確認ack包，那麼這個包的數據內容有長度嗎？或者換一種問法，這種情況下客戶端對伺服器發送的數據包的ack欄位變不變？(不是正常的ack和seq依次遞增情況)
伺服器明明沒有數據要發送的，那麼客戶端的ack欄位是可以一直不變的吧。
--------—------------------------------以上是原問題----------------------------------------------------------—
首先感謝回答。
我自己的解決思路已經放到我的回答裡面了，自問自答了。

關於ACK序號的問題，不存在重複的ACK，因為在握手階段，確認序號將發送方的序號加1作為回答，在數據傳輸階段，確認序號將發送方的序號加發送的數據大小作為回答，表示確實收到這些數據。

關於客戶端上傳數據時，伺服器返回的數據包有沒有TCP數據段的問題，題主你把應用層協議和傳輸層協議混淆了，客戶端上傳數據時雖然伺服器不需要返回應用數據，但是在TCP層面上，仍然存在數據段需要返回，例如客戶端使用HTTP等應用層協議進行上傳的時候，伺服器還需要返回應用層協議的控制協議數據。之前說的時候考慮不周，FTP的命令通道和數據通道是分離的，而HTTP是走一個通道。

你可以去下載一個sniffer觀察一下，會比較清楚。

看了問題很長時間，以下是我自己的看法。
這是流程示意圖：

先確定seq的意義：seq是發送端發送數據的第一個位元組編號。

三次握手中的第三個包中seq=1，是因為客戶端與伺服器建立連接時消耗一個序號，所以第二個包中ack=1。此時第三個包的數據的編號起始為1，則seq=1。

後面兩個客戶返回的數據確認包中seq=1，ack=服務端數據+1；那麼說明此時客戶端發給服務端的確認包未消耗序號，還是1，則客戶未發送數據給服務端，seq一直為1。

手機碼字，見諒，這只是我的想法，請指教，謝謝。

瀉藥。
建議重讀《計算機網路原理》一書關於TCP那一章。
為嘛？因為我也在讀。

問題已解決。不用回答了。另外樓上的大學生們，你們說的欄位關係我都知道，，，題主沒你們想的那麼弱，心塞，不知道國人謙虛？對於樓上讓我重讀還有推薦書的人我只能說反對+沒有幫助。。沒看到我又更新的問題裡面已經把問題解決了嗎，當時是我沒時間去驗證，後來想想可以自己構建一個符合我的猜想的環境。算了不說了，還要準備考級。。直接把答案自己回答了算了。
----------------------------------------------------------------------------------------
昨晚有空，我自己用wireshark，自己搭建了一個ftp伺服器讓手機訪問試了試，搜索條件就是
「ip.host=客戶端ipftp」發現ack是變化的，然後發現有個ftp-data.我搜索這個ftp-data發現伺服器給客
戶端傳送數據的時候ack（小寫）是不變的和大寫ACK一樣一直都是1
。（ftp傳輸有兩個步驟，不知道的看現在第一的回答下的評論就好了）
如下圖，應該能看到客戶端ip是.2 伺服器ip是.1

1. 客戶端這邊發來的seq一直是1，ack在變化。
那說明是ftp伺服器單純的採用主動方式提供數據，而客戶端只需要發送沒有數據的確認。
2.伺服器發來的ack一直是1，seq在變化。那說明此時客戶端是沒數據的。
到這裡這和我的猜想差不多了：
在一個傳輸過程中，分別有一方的seq或者ack是不變的這種情況是存在的！而且這種情況下數據報的數據部分長度肯定一直都是0

另外重複ack應該是我理解錯了，那個是對丟失的報文而言的。
還有一點：

切記眼高手低

自頂向下多看兩遍要不謝希仁那本

題主沒有明白ack的含義，題主以為:ack是用於通信雙方對於數據內容的回應。實際上，ack的作用:用於確認上次對方發送來的數據，並指出下一次想要接受數據的序號。這兩種理解是有區別的，第一種對內容進行回應，那麼，當一方沒有真實的內容要上傳時，就沒必要回應ack，如題主理解。
事實，之所以有ack,是為了保證信息傳輸的可靠，一般情況下要傳輸的內容總是很大的，由於中間要經過很多網路部件，各種網路部件（比如路由器，交換機等）一次所能傳輸的信息片段大小不一，原始的文件被分成很多小塊，也許由不同路由到達目的點，由各路由器的路由選擇演算法決定，它們到達的次序並不一定是按文件本身的先後順序，這時，目的源需要有一種辦法區別某片段與一片段先後關係。由此看，不管一方是否有有意義的數據發送，都需要ack,需要修改ack.
但是，如果一方接受數據時在某個ack總是失敗，那麼接受方會一直發送該ack,另外一種處理辦法是採用滑窗機制，先不理睬未收到序號的內容，而是繼續接受後面的序號，過段時間再檢查那個丟失的ack是否到來。但總體來說，ack會修改，否則，信息傳輸失敗。
題主若很感興趣，關於這方面的內容，題主可以先看rfc1180，做個大概了解，然後就是有名的tcp三卷本聖經和計算機網路第五版，我也在看。

服務端如果只是返回對客戶端數據的回復的話，返回的欄位中ACK有效，同時數據長度會設置為0，當客戶端收到該消息後，再次發送數據到服務端，Seq會增加，但是因收到的服務端返回的數據長度為0，再次發送數據到服務端中的TCP頭中的ACK位是失效的，確認號此時與意義，不存在重複一說。

雖然樓主作答了我再補充一下。一次tcp連接會創建上行和下行兩個幾乎獨立的流。就是不同方向的數據傳輸。這就是tcp協議實現全雙工的方法。一個流上所有要傳輸的數據每個位元組就有一個編號就叫序列號，seqno。tcp頭中的是當前負載中第一個位元組的序列號。

傳輸過程中，某個方向的數據包中seqno就表示當前方向流中數據發到哪個地方了。而其中的ack欄位表示另一個方向流中，已經接收到哪個地方了。兩者幾乎相互獨立。因此，如果僅有一個方向的流在傳輸數據，另一個方向的流，一般來說其seqno就不會增加，當然其ack也就幾乎不變。

正好最近在研究計算機網路的東西，謝題主(雖然自問自答了)。

我覺得題主應該理清應用層協議和傳輸層協議之間的區別關係。