专有名词

seq（sequence number）：表示我方（发送方）这边，这个 packet 的数据部分的第一位应该在 data stream 中所在的位置。（这里用的是“应该”。因为对于没有数据的传输，如 ACK，虽然它有一个 seq，但是这次传输在整个 data stream 中是不占位置的，所以下一个实际有数据的传输，会从上一次发送 ACK 的数据包的 seq 开始）。
SYN：表示建立连接。传输虽然没有 data，但是会让下一次传输的 packet seq加一。
ACK（acknowledge number）：表示响应。期望对方（接收方）的下一次 sequence number 是多少。但 ACK 的传输不会让下一次的 packet 加一。
FIN（finish）：表示关闭连接。传输虽然也没有 data，但是会让下一次传输的 packet seq加一。
PSH：表示有 DATA数据传输，
RST：表示连接重置。

HTTP 传输过程

这篇文章的标题虽然是连接过程，但这里其实是 HTTP数据交互的一个过程，我们知道HTTP是无连接的，所以这里需要注意下

HTTP数据传输过程

TCP 三次握手连接过程

实例

TCP协议中的seq/ack序号是如何变化的？

TCP数据包交互过程

过程1：客户端发送 SYN 到服务端

seq=0：第一次握手。client 端第一次发送 packet。按照上面的原则，他的数据应该是从第一个开始，也就是第 0 位开始，所以此时 seq=0；
ack=0：server 端之前从未发送过数据。所以 client 期望 server 回传的 seq 是从第一个开始，所以此时 ack=0；

过程2：服务端向客户端返回 ACK，同时，自己也发送一个SYN包，即 SYN + ACK 包

seq=0：第二次握手。server 端第一次发送 packet。上面介绍过了，ack 表示对方期望我方本次传输的 seq 的值，我方（server）接收到的对方（client）传来的 ack=0，说明 client 端希望 server 端回传的 seq=0；
ack=1：在【过程1】中，本次 packet 传输的 seq=0，而 server 端返回的是SYN+ACK，根据上面的规则，SYN 的传输会让 seq+1。server 端知道自己本次传输的有 SYN，所以会告诉 client，下一次的 seq 需要 +1，所以 ack=1；

过程3：客户端收到回应，向服务端发送确认包 ACK

seq=1：第三次握手。【过程2】中，ack=1，server 端期望 client 端的 seq，所以 seq=1；
ack=1：根据上面的原则，ACK 的传输不会让 seq+1。而 client 端知道自己本次传输的是 ACK，所以会告诉 server，下一次的 seq 还是1，所以 ack=1；

到这里，已经完成三次握手，客户端与服务端开始传输数据

过程4：客户端向服务端发送数据请求，len=725

三次握手接受后，客户端和服务端已经建立了连接，服务端不需要再向客户端返回信息。而这里是客户端第一次向服务端发送数据，所以 seq 和 ack 都是用的上一次的结果。

过程5：服务端应答客户端的请求：返回确认包 ACK

seq=1：结果仍然是对方期望的值，客户端的ack=1；
ack=726：本次服务端接收到的 seq=1，数据包长度是 725。服务端本次返回客户端的是 ACK，不会对 seq 造成影响，所以期望的下一次客户端的 seq=1+725；

过程6：服务端响应客户端的请求：返回数据包，len=1448

过程7：客户端收到服务端的响应数据：返回确认包 ACK

后面的过程雷同，就不在展开分析了

TCP 四次挥手

主要过程分为四个

第一次握手：交换基本信息

客户端想服务端法发送一个打招呼报文（hello），包含自己支持的SSL版本、加密算法等信息；
服务端回复一个打招呼报文（hi），包含自己支持的SSL版本、加密算法等信息；
服务端发送自己经过 CA 认证的公开密钥
1. 服务端向 CA 认证机构发送自己的公开密钥（FPKey）
2. CA 认证机构使用自己的私有密钥给 FPKey 加上签名，并返回给服务端；
服务端发送结束招呼报文，SSL第一次握手结束；