目录
客户端与服务器间的三次握手
要想成功创建连接需要客户端和服务端之间完成三次握手。
下图是三次握手的过程：
客户端和服务端之间通过三次握手成功建立连接状态变化的过程：
客户端
CLOSED->SYN_SENT（客户端调用connect，向服务端发送同步报文段）
SYN_SENT->ESTABLISHED（客户端收到服务端的确认报文，connect调用成功并返回）
服务端
CLOSED->LISTEN（服务端调用listen，等待客户端的连接请求）
LISTEN->SYN_RCVD（一旦监听到连接请求即收到同步报文段，服务端的操作系统将该连接加入到内核中的半连接等待队列里）
1、关于SYN_RCVD状态
有一种场景：
当服务端创建、绑定套接字后，然后调用系统调用int blacklog = 1; listen(sockfd,blacklog);使服务端处于等待客户端连接请求的状态，客户端创建、系统自动绑定套接字，然后调用系统调用connect。启动服务端，同时启动3个客户端连接服务端。结果如下图：
可以得到：
对于服务器端主机，查询到的只有两个客户端进程成功建立了连接,连接State是ESTABLISHED；而与另外一个客户端进程建立的连接State是SYN_REVD。
对于客户端主机，查询到的是三个客户端进程与服务端之间的连接State是ESTABLISHED，即都成功建立了连接。
对于客户端应用程序来说，在三次握手中，只要向服务端发送了最后一个确认应答后就认为连接已经被建立好了。对于服务端，必须收到客户端发送的最后一个确认应答才算连接建立成功，但是如果该应答丢失，那就无法成功建立连接。比如当全连接队列被填满时，服务端就不会收到最后一个确认应答。
为什么对于服务端主机查询到的第三个客户端进程与服务无端建立的连接State是SYN_REVD，也就意味着，连接未建立成功，三次握手过程中服务端没有收到客户端的最后确认应答。为什么会出现这种情况？按理说连接应该建立成功的。
这是因为系统调用listen中的第二个参数backlog。
2、关于系统调用listen的第二个参数
服务端在调用listen后，处于等待连接请求的状态，服务端成功建立多个连接，每个连接都有自己的数据结构，OS必须将多个连接管理起来，服务端的操作系统中有一个全连接队列，服务端成功获取的连接就会进入该队列中，每调用一次accept就会从该队列中拿走一个连接，而listen的第二个参数+1就是该队列的最大长度。
服务端操作系统中还存在一个半连接队列 该队列的长度由OS自己定，该队列中的连接状态是SYN_REVD，全连接队列中的连接是从半连接队列中得到的。当大量恶意客户端请求连接服务端，半连接队列就被这些SYN_REVD状态的连接全部占满，正常的客户端就无法与服务端建立连接了，这种情况被称为SYN洪水。
3、为什么服务端操作系统内核中的全连接队列不能太长？
如果上层因为繁忙来不及accept获取全连接队列中的连接，这种情况下全连接队列中大量的连接也没什么用处，并且会占用操作系统大量的内存，操作系统维护这些连接数据结构是有成本的。
4、服务端操作系统内核中可以没有全连接队列？
不能没有全连接队列。如果没有全连接队列会导致服务端资源得不到充分利用，当上层调用accept，全连接队列能够迅速的给上层提供连接，不用等待客户端发起连接请求，节约时间、提高通信效率。