1樓：車小胖
問題1、2:
乙個TCP session 由 source IP + source Port + destination IP + destination Port 唯一決定，一般也稱為 TCP socket，所以即使每個TCP session 的ISN（Initial Sequence Number ）都是相同的也無妨，TCP可以將不同socket的資料提交給不同的應用程序，而不會造成混淆。
但是如果ISN採用靜止的、不變的數字，會有以下潛在問題：
1） Bogus TCP Reset
大型防火牆的工作原理就是一旦發現有訪問blocked website，則需要重置這個連線，步驟如下：偽造乙個TCP reset，包含IP欄位、TCP欄位的偽造，傳送給客戶端，因為所有欄位都是可以接受的，所以客戶端接受這個reset訊息並重置TCP連線。因為流量途徑防火牆，所以包括IP Header 、TCP Header的資訊都能得到，所以很容易偽造。
對於不能接觸到流量的任何第三方能否也可以偽造乙個TCP Reset呢？理論上也是可以的，對於靜態的字段如 source/destination IP/Port 這個比較容易偽造，最難的就是 TCP sequence number ，至少偽造的序列號位於對方的 slide window 視窗之內，而如果採用靜態ISN，則相對容易構造乙個TCP Reset，然後將乙個TCP session 重置了，這很顯然不利於安全。
而如果採用隨著時間而增長的ISN，由於這個ISN是乙個動態的值，所以偽造TCP sequence number 難度增加，所以這個動態增長的ISN一方面是出於安全的考慮。
2）Ambignity of TCP Port Reused
由於允許乙個剛釋放的TCP Port重用，如果已釋放的TCP session 與新建立的TCP session 四原組完全一致，則存在老的session 的資料依然在路上，新的session 也在路上，這樣對方就會被弄迷糊，而無法判斷誰是真正的合法資料。如採用動態增長的ISN，則避免相鄰的兩個TCP session 的 sequence number 的重疊，不會造成誤會。
問題3:
客戶端握手的ACK由於伺服器端斷網而丟棄，此時客戶端為 established 狀態，伺服器端為SYN_Receive狀態，客戶端傳送的資料由於伺服器端的斷網也被丟棄，客戶端啟動超時重傳（timeout retransmit），就這麼一直重傳下去，如果到達retransmit retry limit，則reset 這個TCP連線。如果沒有到達retransmit retry limit 而伺服器端網路恢復，則伺服器端接收客戶端的ACK + Data，伺服器端切換到 established 狀態，並將快取的資料提交給應用程式。
2樓：Rob Zhang
1，，然後才開始處理序列號
2，同一臺機器如果初始序列號都從乙個固定的值開始，更有可能造成困擾，比如，A和B建立了乙個連線，傳送一些資料後斷開連線，其中一些報文在這個過程中發生了重傳而且還存在於網路之中，之後AB之間又建立了乙個連線但IP及port四元組跟上次一樣，那麼上乙個連線的重傳報文如果這時才到達接收端，如果序列號又在合理區間的話接收端可能會以為是本次連線的正常報文。如果取乙個變化的初始序列號，可以降低這種可能性。
3，客戶端不傳送資料的話就永遠不知道伺服器掉線了，除非開啟了tcp的keepalive
3樓：
1. 兩個連線那四元組一定不同啊，這就可以區分了，序列號只是為了標識同連線內包的順序的。
2. 與一一樣，這句話的前提是同乙個連線的包，不同連線的包確實沒有限制。不同連線確實可以ISN一樣，但這會帶來其它問題，暫且不表。
3. 確實是以為鏈結建立成功了。客戶端會直接發資料，然而伺服器端並不會響應資料的ACK，於是導致超時。
實際上有的協議棧實現在第三個包ACK時直接帶資料。但從客戶端來看，這個連線確實是成功建立了。
實際應用中，TCP IP協議棧是如何工作的？
清風竹影 看了一下目前的幾個回答，作為乙個自以為在這方面理解比較深的，從原理和自身的理解來直觀的問答一下 問題一 協議棧是分層的 對於流程分析基本是對的，但是原理還是有很大偏差。協議棧分層應該大家都知道，但是怎麼理解呢？傳送HTTP請求，應用層會向TCP層傳送資料報文。TCP層看到的是資料，它是根據...
在tcp協議中處於last ack狀態的連線，如果一直收不到對方的ack，會一直處於這個狀態嗎？
tcp orphan retries 連線就進入 LAST ACK 狀態，在未等到 ACK 時，會在tcp orphan retries引數的控制下重發 FIN 報文。 TCP 鏈結出錯 連續重傳同乙個 TCP 段意味著遠端主機或網路鏈路可能存在故障。c 當重傳同乙個段的次數超過了乙個比閾值 R1 ...
在python程式中呼叫cpp的庫建立的執行緒是否受制於GIL
Kenneth 搞清楚GIL是什麼。Global Interpreter Lock，不涉及直譯器當然不受控制了。實際上python連你起了執行緒都不知道。 Gavin 用pthread create new的話肯定受限的，寫擴充套件的方式不行。比較簡單的方法我覺得是通過IO呼叫c 的程式。比如sub...