tcp中32位序號詳解
首先解釋一段擷取的網路資料認識一下。(由a_la_lei解釋)
1、-> syn（這一步是初始化傳送端的isn。理論上，它的資料字段沒有任何值，消耗的是乙個虛位元組）
tcp: sequence number = 4071231308
tcp: acknowledgement number = 0
2、<- ack syn（初始化接收端的isn，並對收到的包進行確認。因為確認的方式是累計確認，所以儘管第1步傳輸了乙個虛位元組，但ack仍舊是4071231308+1=4071231309）
tcp: sequence number = 1191340143
tcp: acknowledgement number = 4071231309
3、-> ack（回應第2步的確認。因為第1步消耗的是乙個虛位元組，所以理論上seq應該仍舊是4071231308，但由於協議的具體實現略有不同，這裡又在虛位元組上加1變成4071231309。仍舊是累計確認。）
tcp: sequence number = 4071231309
tcp: acknowledgement number = 1191340144
4、-> ack push 登入資訊（載荷包。因為第3步僅是乙個確認包，它沒有包含任何有效資料，所以這裡的seq仍舊是4071231309。仍舊是對第2步確認）
tcp: sequence number = 4071231309
tcp: acknowledgement number = 1191340144
5、<- ack（僅僅是乙個確認包。仍舊是根據累計確認原則對第4步確認，ack等於4071231309＋有效載荷=4071231337）
tcp: sequence number = 1191340144
tcp: acknowledgement number = 4071231337
6、<- ack push 回應資訊（載荷包。因為第5步僅僅是乙個確認包，所以這裡不消耗任何序號，seq仍舊是1191340144。ack仍舊是對第4步的確認）
tcp: sequence number = 1191340144
tcp: acknowledgement number = 4071231337
7、-> ack（僅僅是乙個確認包。仍舊是根據累計確認原則對第6步確認，ack等於1191340144＋有效載荷=1191340217）
tcp: sequence number = 4071231337
tcp: acknowledgement number = 1191340217
8、<- ack push 第二次回應資訊（載荷包。因為仍舊有資料要傳送，按第7步給予的ack來設定此包的seq。此包的ack仍舊是4071231337）
tcp: sequence number = 1191340217
tcp: acknowledgement number = 4071231337
本流程需要知道的幾個規則：
規則1、累計確認。接收端對收到的載荷包（資料字段有值的tcp包），回應乙個確認包，確認號是所收到包的tcp資料字段最後乙個位元組＋1。
規則2、捎帶確認。載荷包必須捎帶確認字段。這樣可以減少網路流量。
規則3、虛位元組。有些資料報（ack）不攜帶任何資料，所以不消耗序列號，也就是說仍舊保持不變。
TCP報文段中的序號和確認號
前言 序號欄位和確認號字段是tcp報文段首部中兩個最重要的字段，這兩個欄位是tcp可靠傳輸服務的關鍵部分。tcp把資料看成乙個無結構的 有序的位元組流。序號是建立在傳送的字元流之上的，而不是建立在傳送的報文段的序列之上 序號 32bit 乙個報文段的序號是該報文段首位元組的位元組流編號，舉個栗子 假...
Anaconda中32位和64位開發的切換
1 檢視當前版本以及conda的位數 conda info 2 從64位切換到32位開發模式 set conda force 32bit 1 3 再切回64位開發模式 set conda force 32bit 0 在使用conda建立python開發環境前,切換到32位或64位 前提是當的作業系統...
32位和64位系統中資料型別區別
c語言中基本資料型別的長度 32位下 char 1個位元組 不變 指標變數 4個位元組 32位機的定址空間是4個位元組。同理64位編譯器 變化 short int 2個位元組 不變 int 4個位元組 不變 unsigned int 4個位元組 不變 float 4個位元組 不變 double 8個...