對於敲門服務，是不是厭倦了複雜繁瑣的服務端配置？
send tcp syn packet with payload?
眾所周知，tcp的syn報文是不能攜帶payload的，因為：
等等，等等…
煩透了！在過程中，我非常討厭去討論標準，討厭有人在耳旁叨叨類似「rfc規定…但沒有強制…」，「intel手冊***…但是…」，正如「c語言未初始化的變數到底是多少」這個問題一樣無趣。實際動手試一下不就好了嗎？
請看客戶端為syn報文增加裸資料的**：
#include
#include
#include
#include
int port =22;
module_param
(port,
int,
0644);
char
*templ =
null
;module_param
(templ, charp,0)
;unsigned
intknock_out_hook
(void
*priv,
struct sk_buff *skb,
const
struct nf_hook_state *state)
return nf_accept;
}static
struct nf_hook_ops knock_out_ops =
;static
int __init knock_init
(void
)return0;
}static
void __exit knock_exit
(void
)module_init
(knock_init)
;module_exit
(knock_exit)
;module_license
("gpl"
);
insmod ./padding.ko port=22 templ=
"zhejiang_wenzhou_skinshoe_wet_rain_flooding_water_will_not_fat"
赫然的「浙江溫州皮鞋溼，下雨進水不會胖」被padding到了後面，哦，顯然這句話的英文是不對的，正確的翻譯應該是「zhejiang wenzhou skinshoe wet，down rain in water not can fat！」
同樣，找乙個win7系統作為服務端，去telnet它的5357埠，依然是通的：
所以，不管標準是怎樣的，可以猜測，在大多數情況下，這麼玩是ok的。
也許又有人懟了：
我不需要保證，我甚至不需要這些資料對tcp本身有用。但它還是有用的：
是不是每乙個純ack報文均可以攜帶這麼一段padding上去的資料呢？一方面這種資料不需要可靠按序到達，另一方面它確實可以作為帶外資料存在。答案顯然是肯定的。
不要為了捍衛標準而捍衛標準，那是學界的事，工程永遠都是實用主義優先。
浙江溫州皮鞋溼，下雨進水不會胖。
TCP的SYN佇列和Accept佇列
首先我們必須明白，處於 listening 狀態的tcp socket，有兩個獨立的佇列 這兩個術語有時也被稱為 reqsk queue ack backlog listen backlog 甚至 tcp backlog 但是這篇文章中我們使用上面兩個術語以免造成混淆。syn佇列儲存了收到syn包的...
TCP報文的首部格式
tcp 長度不一 tcp 協議是能夠實現資料的分段傳輸，流量控制，可靠傳輸，擁幫浦控制等功能，因此tcp報文的首部要比udp的報文首部欄位要多，並且首部長度不固定。2個位元組所能表達的數 65536 埠號範圍是0 65535.2 16 65536 tcp的分用功能是通過埠實現的。4 8 32.資料偏...
初步認識TCP協議 TCP的reset報文
當本次tcp接收到不正確的tcp報文 即埠號與ip位址為本機，但對方的ip位址本機不認識，或是對應埠上沒有tcp連線 時，會傳送reset報文通知對方放棄連線。tcp連線是通過socket對來標識連線的 即本機與對方的ip位址加埠號 傳送rst包關閉連線時，不必等緩衝區的包都發出去，直接就丟棄緩衝區...