活久見！TCP兩次揮手，你見過嗎？那四次握手呢？
文章持續更新，可以微信搜一搜「小白debug」第一時間閱讀，回覆【教程】獲golang免費視訊教程。本文已經收錄在GitHub https://github.com/xiaobaiTech/golangFamily , 有大廠面試完整考點和成長路線，歡迎Star。
我們都知道，TCP是個面向連線的、可靠的、基於位元組流的傳輸層通訊協議。
那這裡面提到的"面向連線"，意味著需要 建立連線，使用連線，釋放連線。
建立連線是指我們熟知的TCP三次握手。
而使用連線，則是通過一傳送、一確認的形式，進行資料傳輸。
還有就是釋放連線，也就是我們常見的TCP四次揮手。
TCP四次揮手大家應該比較瞭解了，但大家見過三次揮手嗎？還有兩次揮手呢？
都見過？ 那四次握手呢？
今天這個話題，不想只是獵奇，也不想搞冷知識。
我們從四次揮手開始說起，搞點實用的知識點。
TCP四次揮手
簡單回顧下TCP四次揮手。
正常情況下。只要資料傳輸完了，不管是客戶端還是服務端，都可以主動發起四次揮手，釋放連線。
就跟上圖畫的一樣，假設，這次四次揮手是由客戶端主動發起的，那它就是主動方。伺服器是被動接收客戶端的揮手請求的，叫被動方。
客戶端和伺服器，一開始，都是處於ESTABLISHED狀態。
第一次揮手：一般情況下，主動方執行close()或 shutdown()方法，會發個FIN報文出來，表示"我不再傳送資料了"。
第二次揮手：在收到主動方的FIN報文後，被動方立馬回應一個ACK，意思是"我收到你的FIN了，也知道你不再發資料了"。
上面提到的是主動方不再傳送資料了。但如果這時候，被動方還有資料要發，那就繼續發。注意，雖然第二次和第三次揮手之間，被動方是能發資料到主動方的，但主動方能不能正常收就不一定了，這個待會說。
第三次揮手：在被動方在感知到第二次揮手之後，會做了一系列的收尾工作，最後也呼叫一個 close(), 這時候就會發出第三次揮手的 FIN-ACK。
第四次揮手：主動方回一個ACK，意思是收到了。
其中第一次揮手和第三次揮手，都是我們在應用程式中主動觸發的（比如呼叫close()方法），也就是我們平時寫程式碼需要關注的地方。
第二和第四次揮手，都是核心協議棧自動幫我們完成的，我們寫程式碼的時候碰不到這地方，因此也不需要太關心。
另外不管是主動還是被動，每方發出了一個 FIN 和一個ACK 。也收到了一個 FIN 和一個ACK 。這一點大家關注下，待會還會提到。
FIN一定要程式執行close()或shutdown()才能發出嗎？
不一定。一般情況下，通過對socket執行 close() 或 shutdown() 方法會發出FIN。但實際上，只要應用程式退出，不管是主動退出，還是被動退出（因為一些莫名其妙的原因被kill了）, 都會發出 FIN。
FIN 是指"我不再傳送資料"，因此
shutdown()關閉讀不會給對方發FIN, 關閉寫才會發FIN。
如果機器上FIN-WAIT-2狀態特別多，是為什麼
根據上面的四次揮手圖，可以看出，FIN-WAIT-2是主動方那邊的狀態。
處於這個狀態的程式，一直在等第三次揮手的FIN。而第三次揮手需要由被動方在程式碼裡執行close() 發出。
因此當機器上FIN-WAIT-2狀態特別多，那一般來說，另外一臺機器上會有大量的 CLOSE_WAIT。需要檢查有大量的 CLOSE_WAIT的那臺機器，為什麼遲遲不願呼叫close()關閉連線。
所以，如果機器上FIN-WAIT-2狀態特別多，一般是因為對端一直不執行close()方法發出第三次揮手。
主動方在close之後收到的資料，會怎麼處理
之前寫的一篇文章《程式碼執行send成功後，資料就發出去了嗎？》中，從原始碼的角度提到了，一般情況下，程式主動執行close()的時候；
- 如果當前連線對應的
socket的接收緩衝區有資料，會發RST。 - 如果傳送緩衝區有資料，那會等待傳送完，再發第一次揮手的
FIN。
大家知道，TCP是全雙工通訊，意思是傳送資料的同時，還可以接收資料。
Close()的含義是，此時要同時關閉傳送和接收訊息的功能。
也就是說，雖然理論上，第二次和第三次揮手之間，被動方是可以傳資料給主動方的。
但如果 主動方的四次揮手是通過 close() 觸發的，那主動方是不會去收這個訊息的。而且還會回一個 RST。直接結束掉這次連線。
第二第三次揮手之間，不能傳輸資料嗎？
也不是。前面提到Close()的含義是，要同時關閉傳送和接收訊息的功能。
那如果能做到只關閉傳送訊息，不關閉接收訊息的功能，那就能繼續收訊息了。這種 half-close 的功能，通過呼叫shutdown() 方法就能做到。
int shutdown(int sock, int howto);
其中 howto 為斷開方式。有以下取值：
- SHUT_RD：關閉讀。這時應用層不應該再嘗試接收資料，核心協議棧中就算接收緩衝區收到資料也會被丟棄。
- SHUT_WR：關閉寫。如果傳送緩衝區中還有資料沒發，會將將資料傳遞到目標主機。
- SHUT_RDWR：關閉讀和寫。相當於
close()了。
怎麼知道對端socket執行了close還是shutdown
不管主動關閉方呼叫的是close()還是shutdown()，對於被動方來說，收到的就只有一個FIN。
被動關閉方就懵了，"我怎麼知道對方讓不讓我繼續發資料？"
其實，大可不必糾結，該發就發。
第二次揮手和第三次揮手之間，如果被動關閉方想發資料，那麼在程式碼層面上，就是執行了 send() 方法。
int send( SOCKET s,const char* buf,int len,int flags);
send() 會把資料拷貝到本機的傳送緩衝區。如果傳送緩衝區沒出問題，都能拷貝進去，所以正常情況下，send()一般都會返回成功。
然後被動方核心協議棧會把資料發給主動關閉方。
-
如果上一次主動關閉方呼叫的是
shutdown(socket_fd, SHUT_WR)。那此時，主動關閉方不再傳送訊息，但能接收被動方的訊息，一切如常，皆大歡喜。 -
如果上一次主動關閉方呼叫的是
close()。那主動方在收到被動方的資料後會直接丟棄，然後回一個RST。
針對第二種情況。
被動方核心協議棧收到了RST，會把連線關閉。但核心連線關閉了，應用層也不知道（除非被通知）。
此時被動方應用層接下來的操作，無非就是讀或寫。
-
如果是讀，則會返回
RST的報錯，也就是我們常見的Connection reset by peer。 -
如果是寫，那麼程式會產生
SIGPIPE訊號，應用層程式碼可以捕獲並處理訊號，如果不處理，則預設情況下程式會終止，異常退出。
總結一下，當被動關閉方 recv() 返回EOF時，說明主動方通過 close()或 shutdown(fd, SHUT_WR) 發起了第一次揮手。
如果此時被動方執行兩次 send()。
-
第一次
send(), 一般會成功返回。 -
第二次
send()時。如果主動方是通過shutdown(fd, SHUT_WR)發起的第一次揮手，那此時send()還是會成功。如果主動方通過close()發起的第一次揮手，那此時會產生SIGPIPE訊號，程式預設會終止，異常退出。不想異常退出的話，記得捕獲處理這個訊號。
如果被動方一直不發第三次揮手，會怎麼樣
第三次揮手，是由被動方主動觸發的，比如呼叫close()。
如果由於程式碼錯誤或者其他一些原因，被動方就是不執行第三次揮手。
這時候，主動方會根據自身第一次揮手的時候用的是 close() 還是 shutdown(fd, SHUT_WR) ，有不同的行為表現。
-
如果是
shutdown(fd, SHUT_WR)，說明主動方其實只關閉了寫，但還可以讀，此時會一直處於FIN-WAIT-2， 死等被動方的第三次揮手。 -
如果是
close()， 說明主動方讀寫都關閉了，這時候會處於FIN-WAIT-2一段時間，這個時間由net.ipv4.tcp_fin_timeout控制，一般是60s，這個值正好跟2MSL一樣 。超過這段時間之後，狀態不會變成TIME-WAIT，而是直接變成CLOSED。
# cat /proc/sys/net/ipv4/tcp_fin_timeout
60
TCP三次揮手
四次揮手聊完了，那有沒有可能出現三次揮手？
是可能的。
我們知道，TCP四次揮手裡，第二次和第三次揮手之間，是有可能有資料傳輸的。第三次揮手的目的是為了告訴主動方，"被動方沒有資料要發了"。
所以，在第一次揮手之後，如果被動方沒有資料要發給主動方。第二和第三次揮手是有可能合併傳輸的。這樣就出現了三次揮手。
如果有資料要發，就不能是三次揮手了嗎
上面提到的是沒有資料要發的情況，如果第二、第三次揮手之間有資料要發，就不可能變成三次揮手了嗎？
並不是。TCP中還有個特性叫延遲確認。可以簡單理解為：接收方收到資料以後不需要立刻馬上回復ACK確認包。
在此基礎上，不是每一次傳送資料包都能對應收到一個 ACK 確認包，因為接收方可以合併確認。
而這個合併確認，放在四次揮手裡，可以把第二次揮手、第三次揮手，以及他們之間的資料傳輸都合併在一起傳送。因此也就出現了三次揮手。
TCP兩次揮手
前面在四次揮手中提到，關閉的時候雙方都發出了一個FIN和收到了一個ACK。
正常情況下TCP連線的兩端，是不同IP+埠的程式。
但如果TCP連線的兩端，IP+埠是一樣的情況下，那麼在關閉連線的時候，也同樣做到了一端發出了一個FIN，也收到了一個 ACK，只不過正好這兩端其實是同一個socket 。
而這種兩端IP+埠都一樣的連線，叫TCP自連線。
是的，你沒看錯，我也沒打錯別字。同一個socket確實可以自己連自己，形成一個連線。
一個socket能建立連線？
上面提到了，同一個客戶端socket，自己對自己發起連線請求。是可以成功建立連線的。這樣的連線，叫TCP自連線。
下面我們嘗試下復現。
注意我是在以下系統進行的實驗。在mac上多半無法復現。
# cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
通過nc命令可以很簡單的建立一個TCP自連線
# nc -p 6666 127.0.0.1 6666
上面的 -p 可以指定源埠號。也就是指定了一個埠號為6666的客戶端去連線 127.0.0.1:6666 。
# netstat -nt | grep 6666
tcp 0 0 127.0.0.1:6666 127.0.0.1:6666 ESTABLISHED
整個過程中，都沒有服務端參與。可以抓個包看下。
可以看到，相同的socket，自己連自己的時候，握手是三次的。揮手是兩次的。
上面這張圖裡，左右都是同一個客戶端，把它畫成兩個是為了方便大家理解狀態的遷移。
我們可以拿自連線的握手狀態對比下正常情況下的TCP三次握手。
看了自連線的狀態圖，再看看下面幾個問題。
一端發出第一次握手後，如果又收到了第一次握手的SYN包，TCP連線狀態會怎麼變化？
第一次握手過後，連線狀態就變成了SYN_SENT狀態。如果此時又收到了第一次握手的SYN包，那麼連線狀態就會從SYN_SENT狀態變成SYN_RCVD。
// net/ipv4/tcp_input.c
static int tcp_rcv_synsent_state_process()
{
// SYN_SENT狀態下，收到SYN包
if (th->syn) {
// 狀態置為 SYN_RCVD
tcp_set_state(sk, TCP_SYN_RECV);
}
}
一端發出第二次握手後，如果又收到第二次握手的SYN+ACK包，TCP連線狀態會怎麼變化？
第二握手過後，連線狀態就變為SYN_RCVD了，此時如果再收到第二次握手的SYN+ACK包。連線狀態會變為ESTABLISHED。
// net/ipv4/tcp_input.c
int tcp_rcv_state_process()
{
// 前面省略很多邏輯，能走到這就認為肯定有ACK
if (true) {
// 判斷下這個ack是否合法
int acceptable = tcp_ack(sk, skb, FLAG_SLOWPATH | FLAG_UPDATE_TS_RECENT) > 0;
switch (sk->sk_state) {
case TCP_SYN_RECV:
if (acceptable) {
// 狀態從 SYN_RCVD 轉為 ESTABLISHED
tcp_set_state(sk, TCP_ESTABLISHED);
}
}
}
}
一端第一次揮手後，又收到第一次揮手的包，TCP連線狀態會怎麼變化？
第一次揮手過後，一端狀態就會變成 FIN-WAIT-1。正常情況下，是要等待第二次揮手的ACK。但實際上卻等來了 一個第一次揮手的 FIN包， 這時候連線狀態就會變為CLOSING。
// net/
static void tcp_fin(struct sock *sk)
{
switch (sk->sk_state) {
case TCP_FIN_WAIT1:
tcp_send_ack(sk);
// FIN-WAIT-1狀態下，收到了FIN，轉為 CLOSING
tcp_set_state(sk, TCP_CLOSING);
break;
}
}
這可以說是隱藏劇情了。
CLOSING 很少見，除了出現在自連線關閉外，一般還會出現在TCP兩端同時關閉連線的情況下。
處於CLOSING狀態下時，只要再收到一個ACK，就能進入 TIME-WAIT 狀態，然後等個2MSL，連線就徹底斷開了。這跟正常的四次揮手還是有些差別的。大家可以滑到文章開頭的TCP四次揮手再對比下。
程式碼復現自連線
可能大家會產生懷疑，這是不是nc這個軟體本身的bug。
那我們可以嘗試下用strace看看它內部都做了啥。
# strace nc -p 6666 127.0.0.1 6666
// ...
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
fcntl(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
bind(3, {sa_family=AF_INET, sin_port=htons(6666), sin_addr=inet_addr("0.0.0.0")}, 16) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6666), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
// ...
無非就是以建立了一個客戶端socket控制程式碼，然後對這個控制程式碼執行 bind, 繫結它的埠號是6666，然後再向 127.0.0.1:6666發起connect方法。
我們可以嘗試用C語言去復現一遍。
下面的程式碼，只用於復現問題。直接跳過也完全不影響閱讀。
#include <stdio.h>
#include <unistd.h>
#include <sys/socket.h>
#include <stdlib.h>
#include <arpa/inet.h>
#include <ctype.h>
#include <string.h>
#include <strings.h>
int main()
{
int lfd, cfd;
struct sockaddr_in serv_addr, clie_addr;
socklen_t clie_addr_len;
char buf[BUFSIZ];
int n = 0, i = 0, ret = 0 ;
printf("This is a client \n");
/*Step 1: 建立客戶端端socket描述符cfd*/
cfd = socket(AF_INET, SOCK_STREAM, 0);
if(cfd == -1)
{
perror("socket error");
exit(1);
}
int flag=1,len=sizeof(int);
if( setsockopt(cfd, SOL_SOCKET, SO_REUSEADDR, &flag, len) == -1)
{
perror("setsockopt");
exit(1);
}
bzero(&clie_addr, sizeof(clie_addr));
clie_addr.sin_family = AF_INET;
clie_addr.sin_port = htons(6666);
inet_pton(AF_INET,"127.0.0.1", &clie_addr.sin_addr.s_addr);
/*Step 2: 客戶端使用bind繫結客戶端的IP和埠*/
ret = bind(cfd, (struct sockaddr* )&clie_addr, sizeof(clie_addr));
if(ret != 0)
{
perror("bind error");
exit(2);
}
/*Step 3: connect連結伺服器端的IP和埠號*/
bzero(&serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
serv_addr.sin_port = htons(6666);
inet_pton(AF_INET,"127.0.0.1", &serv_addr.sin_addr.s_addr);
ret = connect(cfd,(struct sockaddr *)&serv_addr, sizeof(serv_addr));
if(ret != 0)
{
perror("connect error");
exit(3);
}
/*Step 4: 向伺服器端寫資料*/
while(1)
{
fgets(buf, sizeof(buf), stdin);
write(cfd, buf, strlen(buf));
n = read(cfd, buf, sizeof(buf));
write(STDOUT_FILENO, buf, n);//寫到螢幕上
}
/*Step 5: 關閉socket描述符*/
close(cfd);
return 0;
}
儲存為 client.c 檔案，然後執行下面命令，會發現連線成功。
# gcc client.c -o client && ./client
This is a client
# netstat -nt | grep 6666
tcp 0 0 127.0.0.1:6666 127.0.0.1:6666 ESTABLISHED
說明，這不是nc的bug。事實上，這也是核心允許的一種情況。
自連線的解決方案
自連線一般不太常見，但遇到了也不難解決。
解決方案比較簡單，只要能保證客戶端和服務端的埠不一致就行。
事實上，我們寫程式碼的時候一般不會去指定客戶端的埠，系統會隨機給客戶端分配某個範圍內的埠。而這個範圍，可以通過下面的命令進行查詢
# cat /proc/sys/net/ipv4/ip_local_port_range
32768 60999
也就是隻要我們的伺服器埠不在32768-60999這個範圍內，比如設定為8888。就可以規避掉這個問題。
另外一個解決方案，可以參考golang標準網路庫的實現，在連線建立完成之後判斷下IP和埠是否一致，如果遇到自連線，則斷開重試。
func dialTCP(net string, laddr, raddr *TCPAddr, deadline time.Time) (*TCPConn, error) {
// 如果是自連線，這裡會重試
for i := 0; i < 2 && (laddr == nil || laddr.Port == 0) && (selfConnect(fd, err) || spuriousENOTAVAIL(err)); i++ {
if err == nil {
fd.Close()
}
fd, err = internetSocket(net, laddr, raddr, deadline, syscall.SOCK_STREAM, 0, "dial", sockaddrToTCP)
}
// ...
}
func selfConnect(fd *netFD, err error) bool {
// 判斷是否埠、IP一致
return l.Port == r.Port && l.IP.Equal(r.IP)
}
四次握手
前面提到的TCP自連線是一個客戶端自己連自己的場景。那不同客戶端之間是否可以互聯？
答案是可以的，有一種情況叫TCP同時開啟。
大家可以對比下，TCP同時開啟在握手時的狀態變化，跟TCP自連線是非常的像。
比如SYN_SENT狀態下，又收到了一個SYN，其實就相當於自連線裡，在發出了第一次握手後，又收到了第一次握手的請求。結果都是變成 SYN_RCVD。
在 SYN_RCVD 狀態下收到了 SYN+ACK，就相當於自連線裡，在發出第二次握手後，又收到第二次握手的請求，結果都是變成 ESTABLISHED。他們的原始碼其實都是同一塊邏輯。
復現TCP同時開啟
分別在兩個控制檯下，分別執行下面兩行命令。
while true; do nc -p 2224 127.0.0.1 2223 -v;done
while true; do nc -p 2223 127.0.0.1 2224 -v;done
上面兩個命令的含義也比較簡單，兩個客戶端互相請求連線對方的埠號，如果失敗了則不停重試。
執行後看到的現象是，一開始會瘋狂失敗，重試。一段時間後，連線建立完成。
# netstat -an | grep 2223
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 127.0.0.1:2224 127.0.0.1:2223 ESTABLISHED
tcp 0 0 127.0.0.1:2223 127.0.0.1:2224 ESTABLISHED
期間抓包獲得下面的結果。
可以看到，這裡面建立連線用了四次互動。因此可以說這是通過"四次握手"建立的連線。
而且更重要的是，這裡面只涉及兩個客戶端，沒有服務端。
看到這裡，不知道大家有沒有跟我一樣，被重新整理了一波認知，對socket有了重新的認識。
在以前的觀念裡，建立連線，必須要有一個客戶端和一個服務端，並且服務端還要執行一個listen()和一個accept()。而實際上，這些都不是必須的。
那麼下次，面試官問你"沒有listen()， TCP能建立連線嗎？"， 我想大家應該知道該怎麼回答了。
但問題又來了，只有兩個客戶端，沒有listen() ，為什麼能建立TCP連線？
如果大家感興趣，我們以後有機會再填上這個坑。
總結
-
四次揮手中，不管是程式主動執行
close()，還是程式被殺，都有可能發出第一次揮手FIN包。如果機器上FIN-WAIT-2狀態特別多，一般是因為對端一直不執行close()方法發出第三次揮手。 -
Close()會同時關閉傳送和接收訊息的功能。shutdown()能單獨關閉傳送或接受訊息。 -
第二、第三次揮手，是有可能合在一起的。於是四次揮手就變成三次揮手了。
-
同一個socket自己連自己，會產生TCP自連線，自連線的揮手是兩次揮手。
-
沒有
listen，兩個客戶端之間也能建立連線。這種情況叫TCP同時開啟，它由四次握手產生。
最後
今天提到的，不管是兩次揮手，還是自連線，或是TCP同時開啟什麼的。
咋一看，可能對日常搬磚沒什麼用，實際上也確實沒什麼用。
並且在面試上大概率也不會被問到。
畢竟一般面試官也不在意茴字有幾種寫法。
這篇文章的目的，主要是想從另外一個角度讓大家重新認識下socket。原來TCP是可以自己連自己的，甚至兩個客戶端之間，不用服務端也能連起來。
這實在是，太出乎意料了。
如果文章對你有幫助，歡迎.....
算了。
兄弟們都是自家人，點不點贊，在不在看什麼的，沒關係的，大家看開心了就好。
在看，點贊什麼的，我不是特別在意，真的，真的，別不信啊。
不三連也真的沒關係的。
兄弟們不要在意啊。
我是虛偽的小白，我們下期見！