04 TCP三次握手：怎么使用套接字格式建立连接？

你好，我是盛延敏，这里是网络编程实战第4讲，欢迎回来。

在上一讲里我们介绍了IPv4、IPv6以及本地套接字格式，这一讲我们来讲一讲怎么使用这些套接字格式完成连接的建立，当然，经典的TCP三次握手理论也会贯穿其中。我希望经过这一讲的讲解，你会牢牢记住TCP三次握手和客户端、服务器模型。

让我们先从服务器端开始。

服务端准备连接的过程

创建套接字

要创建一个可用的套接字，需要使用下面的函数：

int socket(int domain, int type, int protocol)

domain就是指PF_INET、PF_INET6以及PF_LOCAL等，表示什么样的套接字。

type可用的值是：

SOCK_STREAM: 表示的是字节流，对应TCP；
SOCK_DGRAM：表示的是数据报，对应UDP；
SOCK_RAW: 表示的是原始套接字。

参数protocol原本是用来指定通信协议的，但现在基本废弃。因为协议已经通过前面两个参数指定完成。protocol目前一般写成0即可。

bind: 设定电话号码

创建出来的套接字如果需要被别人使用，就需要调用bind函数把套接字和套接字地址绑定，就像去电信局登记我们的电话号码一样。

调用bind函数的方式如下：

bind(int fd, sockaddr * addr, socklen_t len)

我们需要注意到bind函数后面的第二个参数是通用地址格式sockaddr * addr。这里有一个地方值得注意，那就是虽然接收的是通用地址格式，实际上传入的参数可能是IPv4、IPv6或者本地套接字格式。bind函数会根据len字段判断传入的参数addr该怎么解析，len字段表示的就是传入的地址长度，它是一个可变值。

这里其实可以把bind函数理解成这样：

bind(int fd, void * addr, socklen_t len)

不过BSD设计套接字的时候大约是1982年，那个时候的C语言还没有void *的支持，为了解决这个问题，BSD的设计者们创造性地设计了通用地址格式来作为支持bind和accept等这些函数的参数。

对于使用者来说，每次需要将IPv4、IPv6或者本地套接字格式转化为通用套接字格式，就像下面的IPv4套接字地址格式的例子一样：

struct sockaddr_in name;
bind (sock, (struct sockaddr *) &name, sizeof (name)

对于实现者来说，可根据该地址结构的前两个字节判断出是哪种地址。为了处理长度可变的结构，需要读取函数里的第三个参数，也就是len字段，这样就可以对地址进行解析和判断了。

设置bind的时候，对地址和端口可以有多种处理方式。

我们可以把地址设置成本机的IP地址，这相当告诉操作系统内核，仅仅对目标IP是本机IP地址的IP包进行处理。但是这样写的程序在部署时有一个问题，我们编写应用程序时并不清楚自己的应用程序将会被部署到哪台机器上。这个时候，可以利用通配地址的能力帮助我们解决这个问题。通配地址相当于告诉操作系统内核：“Hi，我可不挑活，只要目标地址是咱们的都可以。”比如一台机器有两块网卡，IP地址分别是202.61.22.55和192.168.1.11，那么向这两个IP请求的请求包都会被我们编写的应用程序处理。

那么该如何设置通配地址呢？

对于IPv4的地址来说，使用INADDR_ANY来完成通配地址的设置；对于IPv6的地址来说，使用IN6ADDR_ANY来完成通配地址的设置。

struct sockaddr_in name;
name.sin_addr.s_addr = htonl (INADDR_ANY); /* IPV4通配地址 */

除了地址，还有端口。如果把端口设置成0，就相当于把端口的选择权交给操作系统内核来处理，操作系统内核会根据一定的算法选择一个空闲的端口，完成套接字的绑定。这在服务器端不常使用。

一般来说，服务器端的程序一定要绑定到一个众所周知的端口上。服务器端的IP地址和端口数据，相当于打电话拨号时需要知道的对方号码，如果没有电话号码，就没有办法和对方建立连接。

我们来看一个初始化IPv4 TCP 套接字的例子:

#include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
#include <netinet/in.h>


int make_socket (uint16_t port)
{
  int sock;
  struct sockaddr_in name;


  /* 创建字节流类型的IPV4 socket. */
  sock = socket (PF_INET, SOCK_STREAM, 0);
  if (sock < 0)
    {
      perror ("socket");
      exit (EXIT_FAILURE);
    }


  /* 绑定到port和ip. */
  name.sin_family = AF_INET; /* IPV4 */
  name.sin_port = htons (port);  /* 指定端口 */
  name.sin_addr.s_addr = htonl (INADDR_ANY); /* 通配地址 */
  /* 把IPV4地址转换成通用地址格式，同时传递长度 */
  if (bind (sock, (struct sockaddr *) &name, sizeof (name)) < 0)
    {
      perror ("bind");
      exit (EXIT_FAILURE);
    }


  return sock;
}

listen：接上电话线，一切准备就绪

bind函数只是让我们的套接字和地址关联，如同登记了电话号码。如果要让别人打通电话，还需要我们把电话设备接入电话线，让服务器真正处于可接听的状态，这个过程需要依赖listen函数。

初始化创建的套接字，可以认为是一个"主动"套接字，其目的是之后主动发起请求（通过调用connect函数，后面会讲到）。通过listen函数，可以将原来的"主动"套接字转换为"被动"套接字，告诉操作系统内核：“我这个套接字是用来等待用户请求的。”当然，操作系统内核会为此做好接收用户请求的一切准备，比如完成连接队列。

listen函数的原型是这样的：

int listen (int socketfd, int backlog)

我来稍微解释一下。第一个参数socketdf为套接字描述符，第二个参数backlog，在Linux中表示已完成(ESTABLISHED)且未accept的队列大小，这个参数的大小决定了可以接收的并发数目。这个参数越大，并发数目理论上也会越大。但是参数过大也会占用过多的系统资源，一些系统，比如Linux并不允许对这个参数进行改变。对于backlog整个参数的设置有一些最佳实践，这里就不展开，后面结合具体的实例进行解读。

accept: 电话铃响起了……

当客户端的连接请求到达时，服务器端应答成功，连接建立，这个时候操作系统内核需要把这个事件通知到应用程序，并让应用程序感知到这个连接。这个过程，就好比电信运营商完成了一次电话连接的建立, 应答方的电话铃声响起，通知有人拨打了号码，这个时候就需要拿起电话筒开始应答。

连接建立之后，你可以把accept这个函数看成是操作系统内核和应用程序之间的桥梁。它的原型是：

int accept(int listensockfd, struct sockaddr *cliaddr, socklen_t *addrlen)

函数的第一个参数listensockfd是套接字，可以叫它为listen套接字，因为这就是前面通过bind，listen一系列操作而得到的套接字。函数的返回值有两个部分，第一个部分cliadd是通过指针方式获取的客户端的地址，addrlen告诉我们地址的大小，这可以理解成当我们拿起电话机时，看到了来电显示，知道了对方的号码；另一个部分是函数的返回值，这个返回值是一个全新的描述字，代表了与客户端的连接。

这里一定要注意有两个套接字描述字，第一个是监听套接字描述字listensockfd，它是作为输入参数存在的；第二个是返回的已连接套接字描述字。

你可能会问，为什么要把两个套接字分开呢？用一个不是挺好的么？

这里和打电话的情形非常不一样的地方就在于，打电话一旦有一个连接建立，别人是不能再打进来的，只会得到语音播报：“您拨的电话正在通话中。”而网络程序的一个重要特征就是并发处理，不可能一个应用程序运行之后只能服务一个客户，如果是这样，双11抢购得需要多少服务器才能满足全国 “剁手党 ” 的需求？

所以监听套接字一直都存在，它是要为成千上万的客户来服务的，直到这个监听套接字关闭；而一旦一个客户和服务器连接成功，完成了TCP三次握手，操作系统内核就为这个客户生成一个已连接套接字，让应用服务器使用这个已连接套接字和客户进行通信处理。如果应用服务器完成了对这个客户的服务，比如一次网购下单，一次付款成功，那么关闭的就是已连接套接字，这样就完成了TCP连接的释放。请注意，这个时候释放的只是这一个客户连接，其它被服务的客户连接可能还存在。最重要的是，监听套接字一直都处于“监听”状态，等待新的客户请求到达并服务。

客户端发起连接的过程

前面讲述的bind、listen以及accept的过程，是典型的服务器端的过程。下面我来讲下客户端发起连接请求的过程。

第一步还是和服务端一样，要建立一个套接字，方法和前面是一样的。

不一样的是客户端需要调用connect向服务端发起请求。

connect: 拨打电话

客户端和服务器端的连接建立，是通过connect函数完成的。这是connect的构建函数：

int connect(int sockfd, const struct sockaddr *servaddr, socklen_t addrlen)

函数的第一个参数sockfd是连接套接字，通过前面讲述的socket函数创建。第二个、第三个参数servaddr和addrlen分别代表指向套接字地址结构的指针和该结构的大小。套接字地址结构必须含有服务器的IP地址和端口号。

客户在调用函数connect前不必非得调用bind函数，因为如果需要的话，内核会确定源IP地址，并按照一定的算法选择一个临时端口作为源端口。

如果是TCP套接字，那么调用connect函数将激发TCP的三次握手过程，而且仅在连接建立成功或出错时才返回。其中出错返回可能有以下几种情况：

三次握手无法建立，客户端发出的SYN包没有任何响应，于是返回TIMEOUT错误。这种情况比较常见的原因是对应的服务端IP写错。
客户端收到了RST（复位）回答，这时候客户端会立即返回CONNECTION REFUSED错误。这种情况比较常见于客户端发送连接请求时的请求端口写错，因为RST是TCP在发生错误时发送的一种TCP分节。产生RST的三个条件是：目的地为某端口的SYN到达，然而该端口上没有正在监听的服务器（如前所述）；TCP想取消一个已有连接；TCP接收到一个根本不存在的连接上的分节。
客户发出的SYN包在网络上引起了"destination unreachable"，即目的不可达的错误。这种情况比较常见的原因是客户端和服务器端路由不通。

根据不同的返回值，我们可以做进一步的排查。

著名的TCP三次握手: 这一次不用背记

你在各个场合都会了解到著名的TCP三次握手，可能还会被要求背下三次握手整个过程，但背后的原理和过程可能未必真正理解。我们刚刚学习了服务端和客户端连接的主要函数，下面结合这些函数讲解一下TCP三次握手的过程。这样我相信你不用背，也能根据理解轻松掌握这部分的知识。

这里我们使用的网络编程模型都是阻塞式的。所谓阻塞式，就是调用发起后不会直接返回，由操作系统内核处理之后才会返回。相对的，还有一种叫做非阻塞式的，我们在后面的章节里会讲到。

TCP三次握手的解读

我们先看一下最初的过程，服务器端通过socket，bind和listen完成了被动套接字的准备工作，被动的意思就是等着别人来连接，然后调用accept，就会阻塞在这里，等待客户端的连接来临；客户端通过调用socket和connect函数之后，也会阻塞。接下来的事情是由操作系统内核完成的，更具体一点的说，是操作系统内核网络协议栈在工作。

下面是具体的过程：

客户端的协议栈向服务器端发送了SYN包，并告诉服务器端当前发送序列号j，客户端进入SYNC_SENT状态；
服务器端的协议栈收到这个包之后，和客户端进行ACK应答，应答的值为j+1，表示对SYN包j的确认，同时服务器也发送一个SYN包，告诉客户端当前我的发送序列号为k，服务器端进入SYNC_RCVD状态；
客户端协议栈收到ACK之后，使得应用程序从connect调用返回，表示客户端到服务器端的单向连接建立成功，客户端的状态为ESTABLISHED，同时客户端协议栈也会对服务器端的SYN包进行应答，应答数据为k+1；
应答包到达服务器端后，服务器端协议栈使得accept阻塞调用返回，这个时候服务器端到客户端的单向连接也建立成功，服务器端也进入ESTABLISHED状态。

形象一点的比喻是这样的，有A和B想进行通话：

A先对B说：“喂，你在么？我在的，我的口令是j。”
B收到之后大声回答：“我收到你的口令j并准备好了，你准备好了吗？我的口令是k。”
A收到之后也大声回答：“我收到你的口令k并准备好了，我们开始吧。”

可以看到，这样的应答过程总共进行了三次，这就是TCP连接建立之所以被叫为“三次握手”的原因了。

总结

这一讲我们分别从服务端和客户端的角度，讲述了如何创建套接字，并利用套接字完成TCP连接的建立。

服务器端通过创建socket，bind，listen完成初始化，通过accept完成连接的建立。
客户端通过创建socket，connect发起连接建立请求。

在下一讲里，我们将真正地开始客户端-服务端数据交互的过程。

思考题

最后给你布置两道思考题。

第一道是关于阻塞调用的，既然有阻塞调用，就应该有非阻塞调用，那么如何使用非阻塞调用套接字呢？使用的场景又是哪里呢？

第二道是关于客户端的，客户端发起connect调用之前，可以调用bind函数么？

欢迎你在评论区与我分享你的答案，如果这篇文章帮助你理解TCP三次握手，也欢迎你点击“请朋友读”，把这篇文章分享给你的朋友或者同事。

精选留言（15）

疾风知劲草 👍（211） 💬（18）
之前看过一些文章解释，为什么tcp建立连接需要三次握手，解释如下 tcp连接的双方要确保各自的收发消息的能力都是正常的。客户端第一次发送握手消息到服务端，服务端接收到握手消息后把ack和自己的syn一同发送给客户端，这是第二次握手，当客户端接收到服务端发送来的第二次握手消息后，客户端可以确认“服务端的收发能力OK，客户端的收发能力OK”，但是服务端只能确认“客户端的发送OK，服务端的接收OK”，所以还需要第三次握手，客户端收到服务端的第二次握手消息后，发起第三次握手消息，服务端收到客户端发送的第三次握手消息后，就能够确定“服务端的发送OK，客户端的接收OK”，至此，客户端和服务端都能够确认自己和对方的收发能力OK，，tcp连接建立完成。
2019-08-09

阿卡牛 👍（95） 💬（4）
这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的
2019-08-09

leesper 👍（55） 💬（1）
思考题1：非阻塞调用的场景就是高性能服务器编程！我所有的调用都不需要等待对方准备好了再返回，而是立即返回，那么我怎么知道是否准备好了？就是把这些fd注册到类似select或者epoll这样的调用中，变多个fd阻塞为一个fd阻塞，只要有任何一个fd准备好了，select或者epoll都会返回，然后我们在从中取出准备好了的fd进行各种IO操作，从容自然 ^o^
2019-08-19

鱼向北游 👍（51） 💬（1）
关于三次握手几句话解释清楚 1.信道不安全保证通信需要一来一回 2.客户端的来回和服务端的来回共四次这是最多四次 3.客户端的回和服务端的来合并成一个，就是那个sync k ack j+1 4.这样就是三次握手
2019-09-02

eddy 👍（30） 💬（5）
有个问题, 一次面试中遇到的, 客户端的第三次应答, 服务器没有收到, 然后客户端开始发消息给服务器, 这时候服务器和客户端的表现是什么? 客户端会收到什么返回?
2020-01-09

钱 👍（14） 💬（1）
学完这节，感觉TCP的三次握手机制，更明白了一些，相信此生都会记得，养成了翻评论的习惯，感觉有些同学的解释比老师的还要通俗易懂。我的小结如下，假设只有客户端C和服务端S，两台机器： 1：啥是TCP的三次握手机制？ TCP的三次握手机制，是C和S使用TCP协议进行通信，他们在正式建立链接前，先进行了三次简单的通信，只有这三次简单的同学成功了，才建立正式的连接，之所以说是简单的通信，因为这三次通信发送的消息比较简单，就是固定格式的同步报文和确认报文 2：TCP的三次握手机制的目的是啥？ TCP协议的设计目标之一，就是保证通信信道的安全，而TCP的三次握手机制就是用于确认信道是否安全的手段之一，确认信道安全，最基本的首先要确认C和S都具备信息首发的能力吧！也就是C要确定S能收发信息，S要确定C能收发信息，咋确认呢？那就发送一条消息实验一下呗！所以，就有了TCP的三次握手机制，TCP的三次握手机制的核心目标就是要确认C和S之间的通信信道是安全的。 3：为啥是三次？按道理来讲，C要确认S是否能够正确的收发消息，需要发生一条消息给S，然后接收到S的一条确认收到的消息才行，这一来一回就是两条消息。同理，S要确认C是否能够正确的收发消息，也需要这么玩。这样就需要两趟一来一回，总共需要四次通信，其实这么玩思维上一点负载都是没有的自然而然。不过只是为了确认C和S能否正常通信的话，就如此设计，被聪明一看到就会骂傻X，人类孜孜不倦所追求是更快、更高、更强，计算机世界中这种追求更加的强烈，将S的确认收到C发送的消息和S能正常发生的消息一次性的都发给C岂不是更好，虽然增加了点消息的内容，但是相对于消息的传输消耗而言还是非常少的，而且从整体消耗上看，是减少了一次通信的过程，性能想必会更好。很明显一次握手、两次握手都确认不了C和S的收发消息的能力是否OK。三次握手是比较简洁有效的方式，大于三次之上的握手机制也可以确认C和S是否能够正常通信，不过有些浪费资源了，毕竟三次就能搞定的事情，没必要搞三次至少，毕竟对于性能的追求我们是纳秒必争的。
2019-11-20

rongyefeng 👍（12） 💬（4）
Linux内核2.2之后，socket backlog参数的形为改变了，现在它指等待accept的完全建立的套接字的队列长度，而不是不完全连接请求的数量。不完全连接的长度可以使用/proc/sys/net/ipv4/tcp_max_syn_backlog设置。老师，这里你讲的backlog是未完成连接的队列，是不是有误？
2020-05-14

Arthur.Li 👍（8） 💬（1）
SYN：建立连接 FIN：关闭连接 ACK：响应 PSH：有DATA数据传输 RST：连接重置
2020-04-02

dan 👍（8） 💬（1）
"请问能听见吗""我能听见你的声音，你能听见我的声音吗" A先对B：你在么？我在的，我发一个消息看你能不能收到，我发J； B收到后，回答：我收到了你发的J，你的发送和我的接收功能正常,回你J+1;并且，我给你发个消息K，看我的发送和你的接收是否正常？ A收到后，回答：我收到了你发的J+1和K，我回你K+1，告诉你的发送和我的接收正常；通过前2次，表明：起点的发送和终点的接收，功能正常；通过后2次，表明：终点的发送和起点的接收，功能正常；由此保证：双方可以发送和接收对方的信息。
2020-03-05

weeeee 👍（8） 💬（2）
老师好，有一个问题想请教您一下服务器端的连接进入ESTABLISHED 状态，课程上说的是accept返回后才进入，但是我自己实验发现只要客户端发送ack后，也就是第三次握手完成就进入了ESTABLISHED 状态，和accept没有关系，请问一下老师是我哪里理解错了吗？
2019-08-13

_stuView 👍（6） 💬（7）
sockfd里的这个fd代表什么
2019-08-09

Knight²º¹⁸ 👍（5） 💬（3）
老师我有一个问题，编程语言中的IO模型和操作系统中的IO关系是什么？
2019-08-11

浦上清风 👍（4） 💬（1）
1. 非阻塞 == 异步通信？？？ 2. 可以是可以，但是不安全？？？
2019-08-09

星亦辰 👍（3） 💬（4）
思考题2 客户端可以bind 指定使用固定端口来连接。没有bind 则会产生一个随机的端口来完成连接请求。想到一个比较有意思的事情：客户端bind 以后，对内网进行端口扫描，表象则是，远程随机端口，到本地固定端口完成通信。看似，是本地开启了服务。如果bind 80 443 22这些常规端口，则可以迷惑安全人员 😄
2019-08-09

旅途 👍（2） 💬（3）
老师两个问题麻烦解答下 1.如果服务端使用随机端口那么客户端时怎么知道的不使用随机的话是客户端要先知道服务端的端口然后配置进去吗 2.三次握手时每次通信的消息都加一这个目的是什么每次返回一个"1" 或者"success" 是不是也行?
2019-12-28