1.TCP协议
为什么需要 TCP 协议 ？TCP 工作在哪一层？
IP网络层是不可靠的，TCP工作在传输层，保证数据传输的可靠性。 TCP全称为 "传输控制协议（Transmission Control Protocol"）。
TCP 是面向连接的、可靠的、基于字节流：
- 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
- 可靠的：无论的网络链路中出现了怎样的链路变化，TCP有很多策略 都可以保证一个报文一定能够到达接收端；
- 字节流：用户消息通过 TCP 协议传输时，消息可能会被操作系统「分组」成多个的 TCP 报文，如果接收方的程序如果不知道「消息的边界」，是无法读出一个有效的用户消息的。
2.TCP协议格式详解
-
源端口号和目的端口号：表示数据是从哪个进程来, 到哪个进程去。通过端口号将报文交付给上一层
-
4位TCP报头长度: 表示该TCP头部有多少个32位bit（有多少个4字节）。4个比特位[0000 -1111]最大是15再乘以4个字节（单位），一共能表示60个字节。报头长度 = 固定长度（20字节） + 选项。通过4位TCP报头长度就可以将一个完整报文的报头和有效载荷分离。
-
窗口大小：通过read这样的接口，是将用户级缓冲区的数据拷贝都系统级缓冲区中，主机再将数据通过网络发送到目标主机，其实网络的发送本质也是拷贝。那么如果数据一直发，对方没有来得及接收，大量的数据"打满"了接收缓冲区导致数据丢包的问题，这是一种不可靠 的表现。TCP保证可靠性，通过16位窗口大小来填写自己接收缓冲区的剩余空间，告知对方进行流量控制。
窗口的大小如何告知对方
Client向Server发送数据，Server收到报文会应答。应答也是基于TCP协议通信的，必须是一个完整的TCP报文 （可以没有数据，但至少是完整的报头）！窗口大小通过应答报文告知Client，当然TCP会有**捎带应答（Server也要发送数据捎带的将窗口大小告知对方（数据+应答））**的机制，有可能不会发送单独的应答报文。
-
序列号：用来解决网络包乱序问题。
-
确认序列号：表示确认序列号之前的数据，已经全部收到，下次发送请从确认序列号指定的数字开始发送。
序列号和确认序列号的理解
TCP为了提高效率，不会串行化的传输数据，而是Client发送一批数据给Server。那么Server无法得知报文的顺序而导致数据包乱序的问题，而乱序本身就是一种不可靠的表现 。所以通过序列号，按序接收就能保证顺序问题。
Server对Client发送而来的数据序列号+1，响应确认序列号。表示确认序列号之前的数据，已经全部收到，什么意思呢，如：Server响应2001表示前面发送的2000个字节的数据都收到了，所以允许1001应答报文丢失。确认序列号允许少量的应答报文丢失（这里不携带数据），如果是数据丢失会有重传的机制。
当然序列号的初始值，是在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。
HTTP中会定义一个用户级的缓冲区，想象成一个大数组。系列号会根据数组的下标来确定会更好理解。
-
6个标记位：区分TCP报文的类型
TCP通信需要建立连接，建立完成之后才是正常通信，通信完毕后会断开连接。**不要扯什么，无论是建立连接的报文、正常通信的报文、还是断开连接的报文，都是一个完整的TCP报文！**如何区分是哪种类型的报文呢，这就可以根据报文中的标记位来区分。
-
SYN：设为
1时，表示希望建立连接（称为同步报文段），并在其「序列号」的字段进行序列号初始值的设定 -
ACK：设为
1时，「确认应答」的字段变为有效；TCP 规定除了最初建立连接时的SYN包之外该位必须设置为1。 -
FIN ：设为
1时，表示今后不会再有数据发送，希望断开连接。 -
RST : 设为
1时，对方要求重新建立连接; 把携带RST标识的称为复位报文段 -
PSH：设为
1时，提示接收端应用程序立刻从TCP缓冲区把数据读走。Client一直向服务器发送数据，有可能服务器，很繁忙没来得及读取接收缓存的内容，PSH字段提示接收端应用程序立刻从TCP缓冲区把数据读走；但如果有一个极端，应用程序就没有读取数据的方法，那这不扯了吗，要设计一个程序通信，结果又不读取数据，这像什么话啊！
-
-
URG：设为
1时，紧急指针有效Server服务器负载过大，无法处理Client发来的普通报文，因为报文需要按序排队。但又想知道Server在处理什么工作，可以在编码时设置MSG_OOB（如：1表示IO操作）这样的属性，然后将URG设置为1，让这个报文的紧急字段指向的数据有效，插队处理。
16位紧急指针字段表示紧急数据的首地址，紧急数据不能太大，一般是首地址往后的1个字节
3.TCP的三次握手和四次挥手
3.1.TCP的握手过程
这个地方参照的是小林哥的博客
- 一开始，客户端和服务端都处于
CLOSE状态。先是服务端主动监听某个端口，处于LISTEN状态。 - 客户端会随机初始化序号（
client_isn），将此序号置于 TCP 首部的「序号」字段中，同时把SYN标志位置为1，表示SYN报文。接着把第一个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于SYN-SENT状态。 - 服务端收到客户端的
SYN报文后，首先服务端也随机初始化自己的序号（server_isn），将此序号填入 TCP 首部的「序号」字段中，其次把 TCP 首部的「确认应答号」字段填入client_isn + 1, 接着把SYN和ACK标志位置为1。最后把该报文发给客户端，该报文也不包含应用层数据，之后服务端处于SYN-RCVD状态。 - 客户端收到服务端报文后，还要向服务端回应最后一个应答报文，首先该应答报文 TCP 首部
ACK标志位置为1，其次「确认应答号」字段填入server_isn + 1，最后把报文发送给服务端，这次报文可以携带客户到服务端的数据，之后客户端处于ESTABLISHED状态。 - 服务端收到客户端的应答报文后，也进入
ESTABLISHED状态。
总结
任何一个网络协议都无法保证100%的可靠性！TCP建立连接的时候最后一个ACK应答，没有没有应答的，如果有应答有应答，那就衍生了鸡生蛋蛋生鸡的问题。但是三次握手能保证局部的可靠性。
为什么是三次握手？不是两次？四次？
首要原因是为了防止旧的重复连接初始化造成混乱
客户端先发送了 SYN（seq = 90）报文，然后客户端宕机了，而且这个 SYN 报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接，发送了 SYN（seq = 100）报文（注意！不是重传 SYN，重传的 SYN 的序列号是一样的）
其实，三次握手服务器最后才进入ESTABLISHED，通过这样奇数次连接的方式，如果建立过程中的报文丢失，都可以将失败的成本嫁接到客户端。 另外三次握手保证了通信的全双工验证，保证通信的局部可靠，还有就是可以同步双方初始序列号等。
无论是一次还是两次，客户端向服务端请求连接，SYN到达服务器就立马ESTABLISHED状态，服务器需要创建对应的内核数据结构维持连接，有明显的SYN洪水的问题。
而为什么不是四次，其实也可以是四次，但是TCP有捎带应答的机制，服务器向客户端发送SYN时捎带了ACK。说白了三次握手的最小次数的连接。