1.1OSI 与 TCP/IP 各层的结构
1.2 三次握手和四次挥手，TCP为什么三次握手，四次挥手
在第一次消息发送中，A随机选取一个序列号作为自己的初始序号发送给B；第二次消息B使用ack对A的数据包进行确认，
因为已经收到了序列号为x的数据包，准备接收序列号为x+1的包，所以ack=x+1，同时B告诉A自己的初始序列号，就是seq=y；
第三条消息A告诉B收到了B的确认消息并准备建立连接，A自己此条消息的序列号是x+1，所以seq=x+1，而ack=y+1是表示A正准备接收B序列号为y+1的数据包
1.2.1
为什么收到 Server 端的确认之后，Client 还需要进行第三次“握手”呢？
采用三次握手是为了防止失效的连接请求报文段突然又传送到主机 B ，因而产生错误。
“已失效的连接请求报文段”的产生在这样一种情况下： client 发出的第一个连接请求报 文段并没有丢失，而是在某个网络结点长时间的滞留了（因为网络并发量很大在某结点被
阻塞了），以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的 报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新 的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用“三次握手”， 那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请 求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输 连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。 采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client 不会向 server 的 确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”。主要目的 防止 server 端一直等待，浪费资源。
1.1.3
为什么要 4 次挥手？
确保数据能够完成传输。 但关闭连接时，当收到对方的 FIN 报文通知时，它仅仅表示对方没有数据发送给你了； 但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭 SOCKET,也即你可 能还需要发送一些数据给对方之后，再发送 FIN 报文给对方来表示你同意现在可以关闭连 接了，所以它这里的 ACK 报文和 FIN 报文多数情况下都是分开发送的。 TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当主机 1 发出 FIN 报文段时，只是表示主机 1 已经没有数据要发送了， 主机 1 告诉主机 2，它的数据已经全部发送完毕了；但是，这个时候主机 1 还是可以接受来 自主机 2 的数据；当主机 2 返回 ACK 报文段时，表示它已经知道主机 1 没有数据发送了， 但是主机 2 还是可以发送数据到主机 1 的；当主机 2 也发送了 FIN 报文段时，这个时候就 表示主机 2 也没有数据要发送了，就会告诉主机 1，我也没有数据要发送了，之后彼此就会 愉快的中断这次 TCP 连接。
1.1.4
如何消除大量 TCP 短连接引发的 TIME_WAIT？
可以改为长连接，但代价较大，长连接太多会导致服务器性能问题
修改 ipv4.ip_local_port_range，增大可用端口范围，但只能缓解问题，不能根本 解决问题
1.1.5
当关闭连接时最后一个 ACK 丢失怎么办？
最后一个 ACK 丢失的话，TCP 就会认为它的 FIN 丢失，进行重发 FIN。 在客户端收到 FIN 后，就会设置一个 2MSL 计时器，2MSL 计时器可以使客户等 待足够长的时间，使得在 ACK 丢失的情况下，可以等到下一个 FIN 的到来。如 果在TIME－WAIT状态汇总有一个新的 FIN到达了，客户就会发送一个新的ACK， 并重新设置 2MSL 计时器。
2.1
TCP 如 何 保 证 可 靠 传 输 ？（重点！！！）
0、在传递数据之前，会有三次握手来建立连接。
1、应用数据被分割成 TCP 认为最适合发送的数据块（按字节编号，合理分片）。这和 UDP 完全不同，应用程序产生的数据报长度将保持不变。 (将数据截断为合理的长度)
2、当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不 能及时收到一个确认，将重发这个报文段。(超时重发)
3、当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送， 通常将推迟几分之一秒 。(对于收到的请求，给出确认响应) (之所以推迟，可能是要对包 做完整校验)。
4、TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传 输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到 此报文段。 (校验出包有错，丢弃报文段，不给出响应，TCP 发送数据端，超时时会重发 数据)
5、既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报 文段的到达也可能会失序。如果必要，TCP 将对收到的数据进行重新排序，将收到的数据 以正确的顺序交给应用层。 (对失序数据进行重新排序，然后才交给应用层)
6、既然 IP 数据报会发生重复，TCP 的接收端必须丢弃重复的数据。(对于重复数据，能够 丢弃重复数据)
7、TCP 还能提供流量控制。TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端 只允许另一端发送接收端缓冲区所能接纳的数据。这将防止较快主机致使较慢主机的缓冲 区溢出。(TCP 可以进行流量控制，防止较快主机致使较慢主机的缓冲区溢出)TCP 使用的 流量控制协议是可变大小的滑动窗口协议。
8、TCP 还能提供拥塞控制。当网络拥塞时，减少数据的发送。
1.3
TCP 建立连接之后怎么保持连接（检测连接断没断）？
1. TCP 协议层实现的 Keepalive 机制
2.自己实现的 HeartBeat 心跳包