TCP 协议
五层协议：应用，传输，网络，数据链路，物理 OSI七层：应用层分为 应用，表示，会话
可靠传输
TCP 通过校验和，序列号，确认应答，重发控制，连接管理以及窗口控制等机制实现可靠传输
通过 ACK 的确认应答提高可靠性，当数据发送出去的时候会等待确认应答
未收到ACK不一定代表对方未收到，也可能是确认应答发送回来的途中丢了，超过一定时间间隔发送方会进行重发，其依据就是发送方的序列号和接收方期望接收到的下一个序列号
如何确定超时重传时间？
通过网络环境的情况找到确认应答能够返回的最短时间，因此每次发包都会计算往返时间 RTT（报文段往返时间），若还是收不到确认应答，等待确认应答的时间将会以2倍，4倍以此类推延长，达到一定重发次数后还没有就会强制关闭连接
三次握手，连接建立
建立连接需要3个包 SYN -> connect() 知道号码并拨打 <- SYN, ACK connect返回，accept() 阻塞 ACK -> 确认信息 accept() 返回客户标识 为什么需要第三次握手？ 防止已失效的A请求连接报文又传到B，从而无端占用B的资源。 有第三次握手是因为 B 需要确认 A 当前确实要跟它进行连接，因为上述情况不会有A的确认
四次挥手，释放连接
FIN->，进入等待，关闭 A 发送至 B 的管道 <-ACK确认，可能 B 还要传数据给 A <-ACK，FIN。也进入等待，等待 A 的最后确认，没收到就启动超时重传 -> ACK 确认，B至A的管道关闭，A等待2MSL再关闭，防止旧的失效连接请求报文
TIME_WAIT状态：
- 可靠地实现TCP全双工连接的终止（可能需要重传最后的ACK）
- 允许老的重复分节在网络中消失
拥塞控制
拥塞避免：拥塞窗口倍增直到大于或等于慢开始门限的时候就采用线性增加的做法 快重传：让发送方尽早知道个别报文段的丢失（而不是因为网络拥塞），接收方连续发送 3个ACK，拥塞窗口倍减同时设置为慢开始的门限值，然后启用拥塞避免进行线性增加
流量控制
TCP 总是告知对端在任何时候它能够从对端接收多少个字节，确保数据不会超过缓冲区大小导致缓冲区溢出，当接收数据时窗口就减少，接收端应用从缓冲区读取的时候，窗口又增大，慢的时候必须等待
TCP会为每一个连接都设定一个持续计时器，只要有一方收到对方的零窗口报文段，就启动这个持续计时器。到期之后再发送零窗口控测报文段，对方要返回当前的窗口值，如果仍未0，重设计时器重复上述过程，不为0就可以继续发送了
拆包与粘包
粘包与拆包是由于TCP协议是字节流协议，没有记录边界所导致的。 所以如何确定一个完整的业务包就由应用层来处理了，这就是分包机制，本质上就是要在应用层维护消息与消息的边界 分包机制一般有两个通用的解决方法：
- 特殊字符控制，例如FTP协议
- 在包头首都添加数据包的长度，例如HTTP协议
Nagle 算法
通过对小的数据包进行合并封包（类似buffer缓冲区）减少包的个数来提高 tcp 网络的效率，缓解拥塞
糊涂窗口综合征：应用进程每次可能只取几个字节，会导致每次接收方发送的窗口值过小，因此接收方会等待一段时间或者等到有一半空闲的时候再进行累积确认，顺便还能回复更大的窗口值，提高网络效率
IPV6 与 IPV4
IPv6 使用因特网控制报文协议版本 6（ICMPv6）将这些功能嵌入到 IP 自身作为无状态自动配置和邻节点发现算法的一部分，不需要像 ipv4 一样有 ARP 协议
面试题
TCP/IP层五元组是什么？ 源IP，源端口号，目的IP，目的端口号，传输层协议