迷雾总会解

套接字的创建时机、新创建连接套接字的端口、套接字描述符的解惑

套接字

套接字 socket是操作系统内核的一个数据结构，它是网络中节点进行相互通信的门户。网络编程实际上也可以称作套接字编程。

套接字有3种类型：

流式套接字，即TCP套接字，用SOCK_STREAM表示
数据报套接字，即UDP套接字（或称无连接套接字），用SOCK_DGRAM表示
原始套接字，用SOCK_RAM表示

套接字地址结构由网络地址和端口号组成。

传输方式

（1）TCP

TCP是一个面向连接的传输层协议，在数据发送之前（即进程通信之前)，必须先建立连接。通信完毕后，必须关闭连接。基于TCP传输协议的服务器与客户机间的通信工作流程如下图：

大致流程如下：

服务器先用socket()函数来建立一个套接字，用这个套接字完成通信的监听及数据的收发。
服务器用bind()函数来绑定一个端口号和IP地址，使套接字与指定的端口号和IP地址相关联。
服务器调用listen()函数，使服务器的这个端口和IP处于监听状态，等待网络中某一客户机的连接请求。
客户机用socket()函数建立一个套接字，设定远程IP和端口。
客户机调用connect()函数连接远程计算机指定的端口。
服务器调用accept()函数来接受远程计算机的连接请求，建立起与客户机之间的通信连接。
建立连接以后，客户机用write()函数（或close()函数）向socket中写入数据，也可以用read()函数（或recv()函数）读取服务器发来的数据。
服务器用read()函数（或recv()函数）读取客户机发来的数据，也可以用write()函数（或send()函数）来发送数据。
完成通信以后，使用close()函数关闭socket连接。

（2）UDP

不同于TCP协议，UDP是一个无连接的、不可靠服务的传输层协议，它不对数据进行确认、出错重传和排序等可靠性处理，但它却是具有代码小、实现简单那、速度快和系统开销小等优点。对于某些应用，使用UDP将带来更高的效率，如域名服务系统DNS、网络文件系统NFS等。

基于UDP传输协议的服务器与客户机间的通信工作流程如下图：

对比TCP套接字通信流程，区别在于：

使用TCP套接字必须先建立连接（如客户机进程的connect()，服务器进程的listen()和accept()）

而UDP套接字不需要先建立连接，它在调用socket()生成一个套接字后，在服务器端调用bind()绑定一个端口，然后服务器进程挂起于recvfrom()调用，等待并接收网络中某一客户机的数据请求。而客户端调用sendto()发送数据请求，同样也挂起于recvfrom()调用，等待并接收服务器的应答信号。

当数据传输完毕后，UDP套接字中的客户端调用close()释放通信链路，但不再发送“断开连接通知”信息来通知服务器端释放通信链路。

创建时机

每一个来自客户端的TCP请求在服务器端都会对应一个 socket。事实上，这个新 socket 的创建实机既不是在 listen 的时候，也不是在 accept 的时候，而是在三次握手成功之后创建的，然后放在对应的全连接队列中。

服务端收到客户端发起的 SYN 请求后，内核会把该连接存储到半连接队列，并向客户端响应 SYN+ACK，接着客户端会返回 ACK，如果服务器超时还未收到 ACK 会进行 SYN+ACK 的重传，重传的次数由 tcp_synack_retries 值确定，在 CentOS 上这个值等于 5。服务端收到第三次握手的 ACK 后，内核会把连接从半连接队列移除，然后创建新的完全的连接，并将其添加到全连接队列，等待进程调用 accept 函数时把连接取出来。

accept会阻塞直到3次握手成功为止，也就是说accept发生在三次握手之后(没有accept 3次握手照样成功)。

服务器在 listen 状态的时候可以接收来自客户端的握手请求。当客户端发出的第三次 ack 到达时，服务器创建了新的 sock 对象（socket 的核心），然后加入到了全连接队列中。然后accept的时候，仅仅只是从全连接队列里把 sock 取出来而已。

套接字描述符

套接字描述符是一个整数类型的值，就如程序通过文件描述符访问文件一样，套接字描述符是访问套接字的一种路径。每个进程的进程空间里都有一个套接字描述符表(每个进程维护一个单独的套接字描述符表。因此，应用程序可以拥有相同的套接字描述符)，该表中存放着套接字描述符和套接字数据结构的对应关系。该表中有一个字段存放新创建的套接字的描述符，另一个字段存放套接字数据结构的地址，因此根据套接字描述符就可以找到其对应的套接字数据结构。每个进程在自己的进程空间里都有一个套接字描述符表但是套接字数据结构都是在操作系统的内核缓冲里。

从某种意义上说，套接字也是文件，所以许多对文件描述符使用的函数，对套接字描述符同样适用。每个 socket 被创建后，都会分配两个缓冲区，输入缓冲区和输出缓冲区。

在redis中，当下次这个client端往Redis服务器发送数据的时候，数据就会被内核拷贝到这个socket的输入缓冲区，然后aeEvent模块监听到这个事件就会调用readQueryFromClient函数。

write()/send() 并不立即向网络中传输数据，而是先将数据写入缓冲区中，再写入协议栈，即由TCP协议将数据从缓冲区发送到目标机器。一旦将数据写入到缓冲区，函数就可以成功返回，不管它们有没有到达目标机器，也不管它们何时被发送到网络，这些都是TCP协议负责的事情。
read()/recv() 函数也是如此，也从输入缓冲区中读取数据，而不是直接从网络中读取。

套接字端口

有一个问题：比如我的程序开了一个监听端口，与客户端建立连接之后，生成了一个新套接字。这时我执行了只关闭监听端口的语句，结果却发现监听端口和已建立的连接仍然存在。我都已经关闭了监听套接字，为什么客户端还可以继续往监听端口发信息？这到底是因为什么呢？新套接字和监听套接字有什么关系呢？

监听套接字就是个牵线指路的，你实质上是跟它指的那个人说话。因为你要找的那个人不可能随时等你来，而监听套接字就是专职等你来问，它回答你要找的人在哪，并唤醒你要找的人，于是通话就建立起来了，就像现实生活中的接线员一样。

也就是说，在连接建立后，客户端用发出连接的那个SOCKET向服务器发数据，是发给服务器新创建的SOCKET，而不是服务器的监听SOCKET。服务器的监听SOCKET永远只是用来接受连接请求。

而新创建的SOCKET的端口其实和监听SOCKET是一样的。一般来说一个应用使用一个端口，但是一个应用一般采用一进程多线程，所以各连接套接字的端口是相同的，哪怕是多进程并行应该也是相同的。可以理解为在程序与程序间不能用同一端口，但是在程序内部不同的Socket还是可以用同一端口的。

如果是随机使用一个新的端口，是一定会被防火墙拦截的。

对于tcp，服务器的连接套接字靠四元组唯一标识（本端同，对端不同），监听套接字因为有且只有一个所以靠二元组唯一标识（仅本端），客户端的套接字靠四元组唯一标识（本端不同，对端同），之所以本机收到信息后，能将信息分配到正确的套接字，是通过判断源IP地址和源端口号，如果没有找到匹配源IP地址和源端口号的连接套接字，就把该信息交给监听套接字；对于udp，发送方发过去就完事了，接收方接受一下就完事了，不存在来回来回来回的反复通信，某方的套接字只为本地的那一方负责（收/发那么一下），所以两端都靠二元组唯一标识即可（仅本端）（强调一下“唯一标识套接字”指的是在某一台主机的4和4.5层的多路复用/多路分解时不混淆地区分、标识不同套接字实例）；但是对于某次udp/tcp通信的流向，一定都是四元组，不能把它和套接字混淆。

另外，接收端的应用进程和端口可以是一对一、一对多、多对一的关系，即一个进程可以同时监听多个端口，或多个进程的端口复用。所以，进程和端口并不是像之前想的一定一一对应，端口不同的udp/tcp套接字一定会上交给不同的进程（如80、21，因为协议/服务是不同的则进程一定不同），但端口相同的udp/tcp套接字也可能上交给不同的进程（多进程）、相同进程的不同线程（多线程）。

相关函数

Socket 网络模型的非阻塞模式设置，主要体现在三个关键的函数调用上，如果想要使用 socket 非阻塞模式，就必须要了解这三个函数的调用返回类型和设置模式。

在 socket 模型中，不同操作调用后会返回不同的套接字类型。socket() 方法会返回主动套接字，然后调用 listen() 方法，将主动套接字转化为监听套接字，此时，可以监听来自客户端的连接请求。最后，调用 accept() 方法接收到达的客户端连接，并返回已连接套接字。

针对监听套接字，我们可以设置非阻塞模式：当 Redis 调用 accept() 但一直未有连接请求到达时，Redis 线程可以返回处理其他操作，而不用一直等待。但是，你要注意的是，调用 accept() 时，已经存在监听套接字了。