當前位置:網站首頁>活久見!TCP兩次揮手,你見過嗎?那四次握手呢?

活久見!TCP兩次揮手,你見過嗎?那四次握手呢?

2021-08-20 10:54:14 ilini

活久見!TCP兩次揮手,你見過嗎?那四次握手呢?

文章持續更新,可以微信搜一搜「小白debug」第一時間閱讀,回複【教程】獲golang免費視頻教程。本文已經收錄在GitHub https://github.com/xiaobaiTech/golangFamily , 有大廠面試完整考點和成長路線,歡迎Star。


我們都知道,TCP是個面向連接的、可靠的、基於字節流的傳輸層通信協議。

TCP是什麼

那這裏面提到的"面向連接",意味著需要 建立連接,使用連接,釋放連接。

建立連接是指我們熟知的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()方法發出第三次揮手。

FIN-WAIT-2特別多的原因


主動方在close之後收到的數據,會怎麼處理

之前寫的一篇文章《代碼執行send成功後,數據就發出去了嗎?》中,從源碼的角度提到了,一般情况下,程序主動執行close()的時候;

  • 如果當前連接對應的socket接收緩沖區有數據,會發RST
  • 如果發送緩沖區有數據,那會等待發送完,再發第一次揮手的FIN

大家知道,TCP是全雙工通信,意思是發送數據的同時,還可以接收數據。

Close()的含義是,此時要同時關閉發送和接收消息的功能。

也就是說,雖然理論上,第二次和第三次揮手之間,被動方是可以傳數據給主動方的。

但如果 主動方的四次揮手是通過 close() 觸發的,那主動方是不會去收這個消息的。而且還會回一個 RST。直接結束掉這次連接。

close()觸發TCP四次揮手


第二第三次揮手之間,不能傳輸數據嗎?

也不是。前面提到Close()的含義是,要同時關閉發送和接收消息的功能。

那如果能做到只關閉發送消息不關閉接收消息的功能,那就能繼續收消息了。這種 half-close 的功能,通過調用shutdown() 方法就能做到。

int shutdown(int sock, int howto);

其中 howto 為斷開方式。有以下取值:

  • SHUT_RD:關閉讀。這時應用層不應該再嘗試接收數據,內核協議棧中就算接收緩沖區收到數據也會被丟弃。
  • SHUT_WR:關閉寫。如果發送緩沖區中還有數據沒發,會將將數據傳遞到目標主機。
  • SHUT_RDWR:關閉讀和寫。相當於close()了。

shutdown觸發的TCP四次揮手


怎麼知道對端socket執行了close還是shutdown

不管主動關閉方調用的是close()還是shutdown(),對於被動方來說,收到的就只有一個FIN

被動關閉方就懵了,"我怎麼知道對方讓不讓我繼續發數據?"

其實,大可不必糾結,該發就發。

第二次揮手和第三次揮手之間,如果被動關閉方想發數據,那麼在代碼層面上,就是執行了 send() 方法。

int send( SOCKET s,const char* buf,int len,int flags);

send() 會把數據拷貝到本機的發送緩沖區。如果發送緩沖區沒出問題,都能拷貝進去,所以正常情况下,send()一般都會返回成功。

![tcp_sendmsg 邏輯](https://cdn.jsdelivr.net/gh/xiaobaiTech/image/tcp_sendmsg 邏輯.png)

然後被動方內核協議棧會把數據發給主動關閉方。

  • 如果上一次主動關閉方調用的是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三次揮手


如果有數據要發,就不能是三次揮手了嗎

上面提到的是沒有數據要發的情况,如果第二、第三次揮手之間有數據要發,就不可能變成三次揮手了嗎?

並不是。TCP中還有個特性叫延遲確認。可以簡單理解為:接收方收到數據以後不需要立刻馬上回複ACK確認包。

在此基礎上,不是每一次發送數據包都能對應收到一個 ACK 確認包,因為接收方可以合並確認。

而這個合並確認,放在四次揮手裏,可以把第二次揮手、第三次揮手,以及他們之間的數據傳輸都合並在一起發送。因此也就出現了三次揮手。

TCP三次揮手延遲確認


TCP兩次揮手

前面在四次揮手中提到,關閉的時候雙方都發出了一個FIN和收到了一個ACK

正常情况下TCP連接的兩端,是不同IP+端口的進程。

但如果TCP連接的兩端,IP+端口是一樣的情况下,那麼在關閉連接的時候,也同樣做到了一端發出了一個FIN,也收到了一個 ACK,只不過正好這兩端其實是同一個socket

TCP兩次揮手

而這種兩端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

整個過程中,都沒有服務端參與。可以抓個包看下。

image-20210810093309117

可以看到,相同的socket,自己連自己的時候,握手是三次的。揮手是兩次的。

TCP自連接

上面這張圖裏,左右都是同一個客戶端,把它畫成兩個是為了方便大家理解狀態的遷移。

我們可以拿自連接的握手狀態對比下正常情况下的TCP三次握手。

正常情况下的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同時打開在握手時的狀態變化,跟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是可以自己連自己的,甚至兩個客戶端之間,不用服務端也能連起來。

這實在是,太出乎意料了。



如果文章對你有幫助,歡迎.....

算了。

兄弟們都是自家人,點不點贊,在不在看什麼的,沒關系的,大家看開心了就好。

在看,點贊什麼的,我不是特別在意,真的,真的,別不信啊。

不三連也真的沒關系的。

兄弟們不要在意啊。

我是虛偽的小白,我們下期見!


別說了,一起在知識的海洋裏嗆水吧

版權聲明
本文為[ilini]所創,轉載請帶上原文鏈接,感謝
https://cht.chowdera.com/2021/08/20210820105413692v.html

隨機推薦