http封装请求数据包以后传给传输层，tcp协议部分开始运作。这里将数据包和TCP报头生成TCP报文，打包成新的数据包。
TCP报文结构
三次握手：
在通信之前，会先通过三次握手的机制来确认两端口之间的连接是否可用。而UDP是不需要确认的，直接传
最开始的时候客户端和服务器都是处于CLOSED状态。主动打开连接的为客户端，被动打开连接的是服务器。
某个时刻客户端和服务器要进行通信，此时双方都有备好的端口，服务器的端口会处于监听状态，等待客户端的连接
怎么知道服务器端口号的？
http在访问url中已经拿到！
怎么知道客户端要连接进来，服务器才进入listen状态？
TCP老早就创建了传输控制块TCB，时刻待命准备接受客户端的连接请求，此时服务器就被动地进入了listen状态。
第一次握手：
客户端想要连接，创建传输控制块TCB，状态变为主动打开。发送给服务器不包含数据内容的连接请求报文。该请求报文首部中同步位SYN=1，同时选择一个初始序列号seq=x（携带了x个字节）。然后客户端进入 SYN-SENT （同步已发送）状态，告诉服务器我想和你同步连接。TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
第二次握手：
TCP服务器收到连接请求报文，如果同意连接则发送确认报文。为了保证下次客户端发送报文时seq序列号是正确的，需要发送确认号ack=x+1，同时确认号ack要生效必须发送ACK=1，再加上同步位SYN=1，序列号seq=y（携带Y个字节），然后服务器也进 入SYN-RCVD (同步已收到) 状态，完成同步连接。这个报文也是SYN报文，也不能携带数据，但是同样要消耗一个序号。
第三次握手：
客户端收到确认后还要再向服务器发送确认报文。确认报文已经不是请求报文SYN了，不再包含SYN同步位。发送的内容有序列号seq=x+1（和第二次握手的ACK对应），确认号ack=y+1，ACK=1。客户端发送确认报文以后进入ESTABLISHED（已建立）状态，服务器接收到确认报文以后也进入ESTABLISHED状态。此时TCP连接完成建立。
然后就可以发送TCP接收到Http的数据包后生成的新数据包了！
但是貌似看起来两次握手请求就可以完成事，为什么非要三次握手呢？
<
主要是为了防止已经失效的连接请求报文突然又传到了服务器，从而产生错误。
<
如果是两次握手，假设一种情景：客户端发送了第一个请求连接报文并未丢失，只是因为网络问题在网络节点中滞留太久了。由于客户端迟迟没有收到确认报文，以为服务器没有收到。于是再发送一条请求连接报文，此时一路畅通完成两次握手建立连接，传输数据，关闭连接。然后那个前一条龟速的请求报文终于走到了服务器，再次和服务器建立连接，这就造成了不必要的资源浪费。
<
如果是三次握手，就算那一条龟速的请求报文最后到达了服务器，然后服务器也发送了确认连接报文，但是此时客户端已经不会再发出确认报文了，服务器也接受不到确认报文，于是无法建立连接。
四次挥手：
数据传输完毕后，双方都可释放连接。最开始的时候，客户端和服务器都是处于ESTABLISHED状态，然后客户端主动关闭，服务器被动关闭。
第一次挥手：
客户端从ESTABLISHED状态变为主动关闭状态，客户端发送请求释放连接报文给服务器，FIN=1，seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
第二次挥手：
服务器接收到客户端发来的请求释放报文以后，发送确认报文告诉客户端我收到了你的请求，内容差不多就是seq=v，ack=u+1，ACK=1，此时服务器进入CLOSE-WAIT（关闭等待）状态。
为什么是CLOSE-WAIT状态？可能自己服务器这端还有数据没有发送完，所以这个时候整个TCP的连接就变成了半关闭状态。服务器还能发送数据，客户端也能接收数据，但客户端不能再发送数据了，只能发送确认报文。
客户端接收到服务器传来的确认报文以后，进入 FIN-WAIT-1（终止等待2）状态，等待服务器发送连接释放的报文（在这之前，还需要接受服务器没有发送完的最后的数据）。
第三次挥手：
服务器所有的数据都发送完了，认为可以关闭连接了，于是向客户端发送连接释放报文，内容FIN=1，seq=w，ack=u+1（客户端没发送消息，所以提醒客户端下一次还是从u+1开始发送序列），ACK=1。此时服务器进入了 LAST-ACK（最后确认）状态，等待客户端发送确认报文。
第四次挥手：
客户端接收到了服务器发送的连接释放报文，必须发出确认。确认报文seq=u+1，ack=w+1，ACK=1。此时客户端进入 TIME-WAIT （时间等待）状态，但是没有立马关闭。此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
因为这个确认报文可能丢失。服务器收不到确认报文心想这可能是我没传到或者丢失了啊，于是服务器再传一个FIN，然后客户端再重新发送一个确认报文。然后刷新2∗∗MSL时间。直到这个时间内收不到FIN连接释放报文，客户端撤销TCB进入CLOSE状态。
而服务器，在接收到确认报文的时候就立马变为CLOSE状态了。所以服务器结束TCP连接的时间略早于客户端。
万一确认连接以后客户端故障怎么办？
TCP设有一个保活计时器。显然客户端故障时服务器不会智障般等下去，白白浪费资源。服务器每次收到一次客户端的请求以后都会刷新这个保活计时器，时间通常设置为2小时。若2个小时依旧没有收到客户端的任何数据，服务器会发送一个探测报文段，每隔75分钟发一个，如果连发十个都没有数据反应，那么服务器就知道客户端故障了，关闭连接。
收工
转发原文：cccrush_