TCP握手与socket通信细节

协议与接口

对于程式开发者而言，几乎每天都需要和协议和接口打交道，尽管有时候很少直接使用他们。开发一个应用程序，为了提高开发效率，往往会选择一个框架/库来进行开发，于是乎不可避免的就需要了解框架的API接口。协议往往是一些底层的通信规则，框架的最大职能就是实现和解析这些协议，并指定一套简洁的接口提供给开发者使用。

对于web编程，TCP，HTTP协议最熟悉不过了。TCP握手与挥手中，我们了解了TCP连接相关的具体状态细节。这些算是协议上的规定，对于程式而言，需要如何实现这些协议的从而提供接口呢？所幸，socket的为网络通信协议提供了编程接口。下面就来讨论tcp连接中的socket编程。

socket编程

socket就是不同计算机之间进行通信的一个抽象。socket是两个节点之间的数据传输，端点可能处于同一台主机，也可能位于不同的主机中，通常属于C/S架构，一个连接发起者（initiator）另外一个连接侦听者（listener），通常将从事侦听的socket称作“服务器”，将发起连接的套接字称作“客户端”。一图胜千言，下图几位常见的clinet-server通信模型：

对于服务器，绑定固定的端口，用于监听，客户端如果没有绑定，操作系统会自动分配绑定一个端口

socket与握手细节

从最上面的网络模型图看出，握手的连接发生在客户端connect，服务端的accept返回连接。握手的细节其实是客户端connet和服务端的listen过程，而accept只是返回队列里的连接。下面通过nc和wireshaker抓包来分析tcp三次握手和socket的通信细节。

client创建socket，server尚未bind地址

server如果尚未绑定地址，clinet就发起连接，将会收到一个RST拒绝连接的包。修改server.py运行

import socket
import time

address = ('127.0.0.1', 8000)
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)

while True:
    print 'sleep'
    time.sleep(1)

client运行之后，connect调用之后触发了一个异常，程序退出。查看连接情况如下：

netstat -nat | grep -i "8000" | grep 127.0.0.1

可见并没有创建连接通道，使用wireshaker的抓包如下：

这个过程对于客户端是

客户端发送一个握手包(SYN Seq)
端口直接返回（RST, ACK）拒绝连接

server bind 绑定地址

接下来把server的地址进行绑定，但是尚未监听。运行服务端

import socket
import time

address = ('127.0.0.1', 8000)
# 创建 tcp socket
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定地址
server.bind(address)

while True:
    print 'sleep'
    time.sleep(1)

使用nc查看连接情况

netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         *.*                    CLOSED

然后运行client.py代码，这一次并不像之前connect调用就出现异常，而是客户端阻塞了一段时间之后，最后超时退出。查看wireshaker如下：

客户端发送一个握手包(SYN Seq)
端口没有响应，导致客户端一直重发，此时connect阻塞，直到超时退出(退出进程)。

此时再使用netstat查看会得到如下结果：

☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.55808        127.0.0.1.8000         SYN_SENT
tcp4       0      0  127.0.0.1.8000         *.*                    CLOSED
☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.55808        127.0.0.1.8000         SYN_SENT
tcp4       0      0  127.0.0.1.8000         *.*                    CLOSED
☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.55808        127.0.0.1.8000         SYN_SENT
tcp4       0      0  127.0.0.1.8000         *.*                    CLOSED
☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         *.*                    CLOSED

通过wireshaker和netstat的观察，client发送SYN之后，自身状态编程SYS_SENT，server则一直处于CLOSED。这其实是第一次握手，clinet正等待server的ACK，可惜server并没有呼应，最后clinet超时退出。

server进行listen监听

将server.py加上监听调用，listen接口有一个参数，即连接队列中的连接数，通常设置为5，表示如果创建了连接，就存储再连接队列中，这个队列最大的容量是5。在mac上最大的则是128。

server.py

import socket
import time
address = ('127.0.0.1', 8000)
# 创建 tcp socket
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定地址
server.bind(address)
# 监听
server.listen(5)

while True:
    print 'sleep'
    time.sleep(1)

查看连接状况：

☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         *.*                    LISTEN

可见server处于LISTEM状态。

这次我们使用nc工具来进行交互实验：

☁  ~  nc 127.0.0.1 8000

上述命令等同于connect函数的调用，可见运行nc命令之后，客户端一直被阻塞。一段时间之后，再手动command+c 结束 nc 命令。此时再查看连接状态和抓包：

☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         127.0.0.1.55832        ESTABLISHED
tcp4       0      0  127.0.0.1.55832        127.0.0.1.8000         ESTABLISHED
tcp4       0      0  127.0.0.1.8000         *.*                    LISTEN
☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         127.0.0.1.55832        ESTABLISHED
tcp4       0      0  127.0.0.1.55832        127.0.0.1.8000         ESTABLISHED
tcp4       0      0  127.0.0.1.8000         *.*                    LISTEN
☁  ~  netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4       0      0  127.0.0.1.8000         127.0.0.1.55832        CLOSE_WAIT
tcp4       0      0  127.0.0.1.55832        127.0.0.1.8000         FIN_WAIT_2
tcp4       0      0  127.0.0.1.8000         *.*

从netstat和抓包的情况来看，此时client和server进行了三次握手：

客户端发送一个握手包(SYN Seq)，第一次握手，客户端连接状态为 SYS_SEND
服务端端有响应，并发送一个(SYN, ACK)的应答包，第二次握手客户端的状态都变成ESTABLISHED表示可以发送数据了
客户端再向服务端发送（ACK）应答包，第三次握手，建立TCP连接，服务端也可以发送数据。
客户端发送一个[FIN, ACK]的包，表示关闭连接。
服务端发送一个[ACK]包表示确定关闭客户端到服务端的连接。客户端到服务端的连接断了。服务端到客户端的连接还保持。

listen&accept函数

通过上述的实验，可见tcp三次握手发生在client的connect调用之后，server端的listen函数调用之后，但是并不是由listen函数完成的，listen()的作用仅仅告诉内核一些信息，即连接队列的大小，三次握手是以后内核完成的。一旦完成了三次握手，内核就把连接放入连接队列之中。

当socket对象调用accpet函数的时候，就从连接队列中将tcp连接取出并返回。如果连接队列中没有连接，那么accept函数调用将会阻塞（如果socket是非阻塞模式，accept此时会返回，并触发一个异常）。

上述的代码listen只设置了5，如果连接同事超过了5个会怎么样呢？对于unix，server不会对再对建立新连接的握手进行应答，clinet的 connect 就会返回 ETIMEDOUT。可是在linux中server并不会拒绝连接，只是会延时连接，然后accept调用的时候却未必能把已经建立好的连接全部取出来。

总结

tcp握手的系统调用有 connect bind listen函数。python封装的api和C的很像。客户端connect发起握手，接受到服务器的ack应答返回。server在listen调用之后创建连接队列，同时监听端口，客户端connect发起的syn送达，在服务器的内核完成握手。只有当server端调用accept，才从连接队列中取tcp连接，如果连接队列中还没有握手后的连接，那么aceept调用在socket阻塞模式中就会阻塞，在非阻塞模式中则会返回异常错误。