久久6精品,一级a啪啪啪,欧美成人免费视频,清纯唯美一区二区三区,欧美成人综合一区,日韩深喉在线视频,97午夜影院,乱伦视频网站免费

大家好，我是小林。

前段時間，我在群里看到個小伙伴面字節(jié)時遇到的問題：

關(guān)于 close 和 shudown 我在圖解網(wǎng)絡(luò)里也介紹了一下，但是還不是太詳細(xì)。

今天具體給大家分享下 close 和 shudown 的區(qū)別，大家掌握好來，下次就不怕被問啦！

我們都知道，TCP是個面向連接的、可靠的、基于字節(jié)流的傳輸層通信協(xié)議。

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

建立連接是指我們熟知的TCP三次握手。

而使用連接，則是通過一發(fā)送、一確認(rèn)的形式，進行數(shù)據(jù)傳輸。

還有就是釋放連接，也就是我們常見的TCP四次揮手。

TCP四次揮手大家應(yīng)該比較了解了，但大家見過三次揮手嗎？還有兩次揮手呢？

都見過？那四次握手呢？

今天這個話題，不想只是獵奇，也不想搞冷知識。

我們從四次揮手開始說起，搞點實用的知識點。

TCP四次揮手

簡單回顧下TCP四次揮手。

正常情況下。只要數(shù)據(jù)傳輸完了，不管是客戶端還是服務(wù)端，都可以主動發(fā)起四次揮手，釋放連接。

就跟上圖畫的一樣，假設(shè)，這次四次揮手是由客戶端主動發(fā)起的，那它就是主動方。服務(wù)器是被動接收客戶端的揮手請求的，叫被動方。

客戶端和服務(wù)器，一開始，都是處于ESTABLISHED狀態(tài)。

第一次揮手：一般情況下，主動方執(zhí)行close()或 shutdown()方法，會發(fā)個FIN報文出來，表示"我不再發(fā)送數(shù)據(jù)了"。

第二次揮手：在收到主動方的FIN報文后，被動方立馬回應(yīng)一個ACK，意思是"我收到你的FIN了，也知道你不再發(fā)數(shù)據(jù)了"。

上面提到的是主動方不再發(fā)送數(shù)據(jù)了。但如果這時候，被動方還有數(shù)據(jù)要發(fā)，那就繼續(xù)發(fā)。注意，雖然第二次和第三次揮手之間，被動方是能發(fā)數(shù)據(jù)到主動方的，但主動方能不能正常收就不一定了，這個待會說。

第三次揮手：在被動方在感知到第二次揮手之后，會做了一系列的收尾工作，最后也調(diào)用一個 close(), 這時候就會發(fā)出第三次揮手的 FIN-ACK。

第四次揮手：主動方回一個ACK，意思是收到了。

其中第一次揮手和第三次揮手，都是我們在應(yīng)用程序中主動觸發(fā)的（比如調(diào)用close()方法），也就是我們平時寫代碼需要關(guān)注的地方。

第二和第四次揮手，都是內(nèi)核協(xié)議棧自動幫我們完成的，我們寫代碼的時候碰不到這地方，因此也不需要太關(guān)心。

另外不管是主動還是被動，每方發(fā)出了一個 FIN 和一個ACK 。也收到了一個 FIN 和一個ACK 。這一點大家關(guān)注下，待會還會提到。

FIN一定要程序執(zhí)行close()或shutdown()才能發(fā)出嗎？

不一定。一般情況下，通過對socket執(zhí)行 close() 或 shutdown() 方法會發(fā)出FIN。但實際上，只要應(yīng)用程序退出，不管是主動退出，還是被動退出（因為一些莫名其妙的原因被kill了）, 都會發(fā)出 FIN。

FIN 是指"我不再發(fā)送數(shù)據(jù)"，因此shutdown() 關(guān)閉讀不會給對方發(fā)FIN, 關(guān)閉寫才會發(fā)FIN。

如果機器上FIN-WAIT-2狀態(tài)特別多，是為什么

根據(jù)上面的四次揮手圖，可以看出，FIN-WAIT-2是主動方那邊的狀態(tài)。

處于這個狀態(tài)的程序，一直在等第三次揮手的FIN。而第三次揮手需要由被動方在代碼里執(zhí)行close() 發(fā)出。

因此當(dāng)機器上FIN-WAIT-2狀態(tài)特別多，那一般來說，另外一臺機器上會有大量的 CLOSE_WAIT。需要檢查有大量的 CLOSE_WAIT的那臺機器，為什么遲遲不愿調(diào)用close()關(guān)閉連接。

所以，如果機器上FIN-WAIT-2狀態(tài)特別多，一般是因為對端一直不執(zhí)行close()方法發(fā)出第三次揮手。

主動方在close之后收到的數(shù)據(jù)，會怎么處理

之前寫的一篇文章《代碼執(zhí)行send成功后，數(shù)據(jù)就發(fā)出去了嗎？》中，從源碼的角度提到了，一般情況下，程序主動執(zhí)行close()的時候；

如果當(dāng)前連接對應(yīng)的socket的接收緩沖區(qū)有數(shù)據(jù)，會發(fā)RST。
如果發(fā)送緩沖區(qū)有數(shù)據(jù)，那會等待發(fā)送完，再發(fā)第一次揮手的FIN。

大家知道，TCP是全雙工通信，意思是發(fā)送數(shù)據(jù)的同時，還可以接收數(shù)據(jù)。

Close()的含義是，此時要同時關(guān)閉發(fā)送和接收消息的功能。

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

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

第二第三次揮手之間，不能傳輸數(shù)據(jù)嗎？

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

那如果能做到只關(guān)閉發(fā)送消息，不關(guān)閉接收消息的功能，那就能繼續(xù)收消息了。這種 half-close 的功能，通過調(diào)用shutdown() 方法就能做到。

int shutdown(int sock, int howto);

其中 howto 為斷開方式。有以下取值：
SHUT_RD：關(guān)閉讀。這時應(yīng)用層不應(yīng)該再嘗試接收數(shù)據(jù)，內(nèi)核協(xié)議棧中就算接收緩沖區(qū)收到數(shù)據(jù)也會被丟棄。
SHUT_WR：關(guān)閉寫。如果發(fā)送緩沖區(qū)中還有數(shù)據(jù)沒發(fā)，會將將數(shù)據(jù)傳遞到目標(biāo)主機。
SHUT_RDWR：關(guān)閉讀和寫。相當(dāng)于close()了。

怎么知道對端socket執(zhí)行了close還是shutdown

不管主動關(guān)閉方調(diào)用的是close()還是shutdown()，對于被動方來說，收到的就只有一個FIN。

被動關(guān)閉方就懵了，"我怎么知道對方讓不讓我繼續(xù)發(fā)數(shù)據(jù)？"

其實，大可不必糾結(jié)，該發(fā)就發(fā)。

第二次揮手和第三次揮手之間，如果被動關(guān)閉方想發(fā)數(shù)據(jù)，那么在代碼層面上，就是執(zhí)行了 send() 方法。

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

send() 會把數(shù)據(jù)拷貝到本機的發(fā)送緩沖區(qū)。如果發(fā)送緩沖區(qū)沒出問題，都能拷貝進去，所以正常情況下，send()一般都會返回成功。

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

然后被動方內(nèi)核協(xié)議棧會把數(shù)據(jù)發(fā)給主動關(guān)閉方。

如果上一次主動關(guān)閉方調(diào)用的是shutdown(socket_fd, SHUT_WR)。那此時，主動關(guān)閉方不再發(fā)送消息，但能接收被動方的消息，一切如常，皆大歡喜。
如果上一次主動關(guān)閉方調(diào)用的是close()。那主動方在收到被動方的數(shù)據(jù)后會直接丟棄，然后回一個RST。

針對第二種情況。

被動方內(nèi)核協(xié)議棧收到了RST，會把連接關(guān)閉。但內(nèi)核連接關(guān)閉了，應(yīng)用層也不知道（除非被通知）。

此時被動方應(yīng)用層接下來的操作，無非就是讀或?qū)?/strong>。

如果是讀，則會返回RST的報錯，也就是我們常見的Connection reset by peer。
如果是寫，那么程序會產(chǎn)生SIGPIPE信號，應(yīng)用層代碼可以捕獲并處理信號，如果不處理，則默認(rèn)情況下進程會終止，異常退出。

總結(jié)一下，當(dāng)被動關(guān)閉方 recv() 返回EOF時，說明主動方通過 close()或 shutdown(fd, SHUT_WR) 發(fā)起了第一次揮手。

如果此時被動方執(zhí)行兩次 send()。

第一次send(), 一般會成功返回。
第二次send()時。如果主動方是通過 shutdown(fd, SHUT_WR) 發(fā)起的第一次揮手，那此時send()還是會成功。如果主動方通過 close()發(fā)起的第一次揮手，那此時會產(chǎn)生SIGPIPE信號，進程默認(rèn)會終止，異常退出。不想異常退出的話，記得捕獲處理這個信號。

如果被動方一直不發(fā)第三次揮手，會怎么樣

第三次揮手，是由被動方主動觸發(fā)的，比如調(diào)用close()。

如果由于代碼錯誤或者其他一些原因，被動方就是不執(zhí)行第三次揮手。

這時候，主動方會根據(jù)自身第一次揮手的時候用的是 close() 還是 shutdown(fd, SHUT_WR) ，有不同的行為表現(xiàn)。

如果是 shutdown(fd, SHUT_WR) ，說明主動方其實只關(guān)閉了寫，但還可以讀，此時會一直處于 FIN-WAIT-2，死等被動方的第三次揮手。
如果是 close()，說明主動方讀寫都關(guān)閉了，這時候會處于 FIN-WAIT-2一段時間，這個時間由 net.ipv4.tcp_fin_timeout 控制，一般是 60s，這個值正好跟2MSL一樣。超過這段時間之后，狀態(tài)不會變成 `TIME-WAIT`，而是直接變成`CLOSED`。

# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

TCP三次揮手

四次揮手聊完了，那有沒有可能出現(xiàn)三次揮手？

是可能的。

我們知道，TCP四次揮手里，第二次和第三次揮手之間，是有可能有數(shù)據(jù)傳輸?shù)摹５谌螕]手的目的是為了告訴主動方，"被動方?jīng)]有數(shù)據(jù)要發(fā)了"。

所以，在第一次揮手之后，如果被動方?jīng)]有數(shù)據(jù)要發(fā)給主動方。第二和第三次揮手是有可能合并傳輸?shù)摹＿@樣就出現(xiàn)了三次揮手。

如果有數(shù)據(jù)要發(fā)，就不能是三次揮手了嗎

上面提到的是沒有數(shù)據(jù)要發(fā)的情況，如果第二、第三次揮手之間有數(shù)據(jù)要發(fā)，就不可能變成三次揮手了嗎？

并不是。TCP中還有個特性叫延遲確認(rèn)?？梢院唵卫斫鉃椋?strong style="font-size: inherit;line-height: inherit;color: rgb(41, 98, 255);">接收方收到數(shù)據(jù)以后不需要立刻馬上回復(fù)ACK確認(rèn)包。

在此基礎(chǔ)上，不是每一次發(fā)送數(shù)據(jù)包都能對應(yīng)收到一個 ACK 確認(rèn)包，因為接收方可以合并確認(rèn)。

而這個合并確認(rèn)，放在四次揮手里，可以把第二次揮手、第三次揮手，以及他們之間的數(shù)據(jù)傳輸都合并在一起發(fā)送。因此也就出現(xiàn)了三次揮手。

TCP兩次揮手

前面在四次揮手中提到，關(guān)閉的時候雙方都發(fā)出了一個FIN和收到了一個ACK。

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

但如果TCP連接的兩端，IP+端口是一樣的情況下，那么在關(guān)閉連接的時候，也同樣做到了一端發(fā)出了一個FIN，也收到了一個 ACK，只不過正好這兩端其實是同一個socket 。

而這種兩端IP+端口都一樣的連接，叫TCP自連接。

是的，你沒看錯，我也沒打錯別字。同一個socket確實可以自己連自己，形成一個連接。

一個socket能建立連接？

上面提到了，同一個客戶端socket，自己對自己發(fā)起連接請求。是可以成功建立連接的。這樣的連接，叫TCP自連接。

下面我們嘗試下復(fù)現(xiàn)。

注意我是在以下系統(tǒng)進行的實驗。在mac上多半無法復(fù)現(xiàn)。

#  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命令可以很簡單的創(chuàng)建一個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

整個過程中，都沒有服務(wù)端參與?？梢宰€包看下。

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

上面這張圖里，左右都是同一個客戶端，把它畫成兩個是為了方便大家理解狀態(tài)的遷移。

我們可以拿自連接的握手狀態(tài)對比下正常情況下的TCP三次握手。

看了自連接的狀態(tài)圖，再看看下面幾個問題。

一端發(fā)出第一次握手后，如果又收到了第一次握手的SYN包，TCP連接狀態(tài)會怎么變化？

第一次握手過后，連接狀態(tài)就變成了SYN_SENT狀態(tài)。如果此時又收到了第一次握手的SYN包，那么連接狀態(tài)就會從SYN_SENT狀態(tài)變成SYN_RCVD。

// net/ipv4/tcp_input.c
static int tcp_rcv_synsent_state_process()
{
    // SYN_SENT狀態(tài)下，收到SYN包
    if (th->syn) {
        // 狀態(tài)置為 SYN_RCVD
        tcp_set_state(sk, TCP_SYN_RECV);
    }
}

一端發(fā)出第二次握手后，如果又收到第二次握手的SYN+ACK包，TCP連接狀態(tài)會怎么變化？

第二握手過后，連接狀態(tài)就變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">SYN_RCVD了，此時如果再收到第二次握手的SYN+ACK包。連接狀態(tài)會變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">ESTABLISHED。

// net/ipv4/tcp_input.c
int tcp_rcv_state_process()
{
    // 前面省略很多邏輯，能走到這就認(rèn)為肯定有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) {
        // 狀態(tài)從 SYN_RCVD 轉(zhuǎn)為 ESTABLISHED
                tcp_set_state(sk, TCP_ESTABLISHED);
            } 
        }
    }
}

一端第一次揮手后，又收到第一次揮手的包，TCP連接狀態(tài)會怎么變化？

第一次揮手過后，一端狀態(tài)就會變成 FIN-WAIT-1。正常情況下，是要等待第二次揮手的ACK。但實際上卻等來了一個第一次揮手的 FIN包，這時候連接狀態(tài)就會變?yōu)?code style="font-size: inherit;line-height: inherit;padding: 2px 4px;border-radius: 4px;margin-right: 2px;margin-left: 2px;color: rgb(255, 82, 82);background: rgb(248, 248, 248);">CLOSING。

// net/
static void tcp_fin(struct sock *sk)
{
    switch (sk->sk_state) {
    case TCP_FIN_WAIT1:
        tcp_send_ack(sk);
    // FIN-WAIT-1狀態(tài)下，收到了FIN，轉(zhuǎn)為 CLOSING
        tcp_set_state(sk, TCP_CLOSING);
        break;
    }
}

這可以說是隱藏劇情了。

CLOSING 很少見，除了出現(xiàn)在自連接關(guān)閉外，一般還會出現(xiàn)在TCP兩端同時關(guān)閉連接的情況下。

處于CLOSING狀態(tài)下時，只要再收到一個ACK，就能進入 TIME-WAIT 狀態(tài)，然后等個2MSL，連接就徹底斷開了。這跟正常的四次揮手還是有些差別的。大家可以滑到文章開頭的TCP四次揮手再對比下。

代碼復(fù)現(xiàn)自連接

可能大家會產(chǎn)生懷疑，這是不是nc這個軟件本身的bug。

那我們可以嘗試下用strace看看它內(nèi)部都做了啥。

# 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)
// ...

無非就是以創(chuàng)建了一個客戶端socket句柄，然后對這個句柄執(zhí)行 bind, 綁定它的端口號是6666，然后再向 127.0.0.1:6666發(fā)起connect方法。

我們可以嘗試用C語言去復(fù)現(xiàn)一遍。

下面的代碼，只用于復(fù)現(xiàn)問題。直接跳過也完全不影響閱讀。

#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: 創(chuàng)建客戶端端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鏈接服務(wù)器端的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: 向服務(wù)器端寫數(shù)據(jù)*/
    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: 關(guān)閉socket描述符*/
    close(cfd);
    return 0;
}

保存為 client.c 文件，然后執(zhí)行下面命令，會發(fā)現(xiàn)連接成功。

# 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。事實上，這也是內(nèi)核允許的一種情況。

自連接的解決方案

自連接一般不太常見，但遇到了也不難解決。

解決方案比較簡單，只要能保證客戶端和服務(wù)端的端口不一致就行。

事實上，我們寫代碼的時候一般不會去指定客戶端的端口，系統(tǒng)會隨機給客戶端分配某個范圍內(nèi)的端口。而這個范圍，可以通過下面的命令進行查詢

# cat /proc/sys/net/ipv4/ip_local_port_range
32768   60999

也就是只要我們的服務(wù)器端口不在32768-60999這個范圍內(nèi)，比如設(shè)置為8888。就可以規(guī)避掉這個問題。

另外一個解決方案，可以參考golang標(biāo)準(zhǔn)網(wǎng)絡(luò)庫的實現(xiàn)，在連接建立完成之后判斷下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自連接是一個客戶端自己連自己的場景。那不同客戶端之間是否可以互聯(lián)？

答案是可以的，有一種情況叫TCP同時打開。

大家可以對比下，TCP同時打開在握手時的狀態(tài)變化，跟TCP自連接是非常的像。

比如SYN_SENT狀態(tài)下，又收到了一個SYN，其實就相當(dāng)于自連接里，在發(fā)出了第一次握手后，又收到了第一次握手的請求。結(jié)果都是變成 SYN_RCVD。

在 SYN_RCVD 狀態(tài)下收到了 SYN+ACK，就相當(dāng)于自連接里，在發(fā)出第二次握手后，又收到第二次握手的請求，結(jié)果都是變成 ESTABLISHED。他們的源碼其實都是同一塊邏輯。

復(fù)現(xiàn)TCP同時打開

分別在兩個控制臺下，分別執(zhí)行下面兩行命令。

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

上面兩個命令的含義也比較簡單，兩個客戶端互相請求連接對方的端口號，如果失敗了則不停重試。

執(zhí)行后看到的現(xiàn)象是，一開始會瘋狂失敗，重試。一段時間后，連接建立完成。

# 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

期間抓包獲得下面的結(jié)果。

可以看到，這里面建立連接用了四次交互。因此可以說這是通過"四次握手"建立的連接。

而且更重要的是，這里面只涉及兩個客戶端，沒有服務(wù)端。

看到這里，不知道大家有沒有跟我一樣，被刷新了一波認(rèn)知，對socket有了重新的認(rèn)識。

在以前的觀念里，建立連接，必須要有一個客戶端和一個服務(wù)端，并且服務(wù)端還要執(zhí)行一個listen()和一個accept()。而實際上，這些都不是必須的。

那么下次，面試官問你"沒有listen()， TCP能建立連接嗎？"，我想大家應(yīng)該知道該怎么回答了。

但問題又來了，只有兩個客戶端，沒有listen() ，為什么能建立TCP連接？

如果大家感興趣，我們以后有機會再填上這個坑。

總結(jié)

四次揮手中，不管是程序主動執(zhí)行close()，還是進程被殺，都有可能發(fā)出第一次揮手FIN包。如果機器上FIN-WAIT-2狀態(tài)特別多，一般是因為對端一直不執(zhí)行close()方法發(fā)出第三次揮手。
Close()會同時關(guān)閉發(fā)送和接收消息的功能。shutdown() 能單獨關(guān)閉發(fā)送或接受消息。
第二、第三次揮手，是有可能合在一起的。于是四次揮手就變成三次揮手了。
同一個socket自己連自己，會產(chǎn)生TCP自連接，自連接的揮手是兩次揮手。
沒有listen，兩個客戶端之間也能建立連接。這種情況叫TCP同時打開，它由四次握手產(chǎn)生。

最后

今天提到的，不管是兩次揮手，還是自連接，或是TCP同時打開什么的。

咋一看，可能對日常搬磚沒什么用，實際上也確實沒什么用。

并且在面試上大概率也不會被問到。

畢竟一般面試官也不在意茴字有幾種寫法。

這篇文章的目的，主要是想從另外一個角度讓大家重新認(rèn)識下socket。原來TCP是可以自己連自己的，甚至兩個客戶端之間，不用服務(wù)端也能連起來。

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

粗暴的關(guān)閉 vs 優(yōu)雅的關(guān)閉

TCP四次揮手

FIN一定要程序執(zhí)行close()或shutdown()才能發(fā)出嗎？

如果機器上FIN-WAIT-2狀態(tài)特別多，是為什么

主動方在close之后收到的數(shù)據(jù)，會怎么處理

第二第三次揮手之間，不能傳輸數(shù)據(jù)嗎？