OSI开放式互联参考模型
- 物理层（原始比特流传输）
- 数据链路层（物理寻址，将原始比特流转变为逻辑传输线路 包含错误检测）
- 网络层（控制子网运行）
- 传输层（必要时将数据进行分割，保证数据段有效到达对端）
- 会话层（管理会话）
- 表示层（语法语义的转换）
- 应用层（确定协议 TCP/IP-HTTP）
TCP/IP协议群
传输控制协议TCP
- 面向链接的、可靠的、基于字节流的传输层通信协议。
- 将应用层的数据流分割成报文段并发送给目标节点的TCP层。
- 数据包都有序号，收到则发送ACK确认，未收到则重传。
- 使用校验和判断数据在传输中是否有错误。
TCP三次握手
- 第一次握手：建立连接时，客户端发送SYN包（
SYN=1,seq=x）到服务器，并进入SYN_SEND状态，等待服务器确认； - 第二次握手：服务器收到SYN包，必须确认客户端的SYN(
ACK=1,ack=x+1)，同时自己也发送一个SYN包（SYN=1,seq=y），即SYN+ACK包，此时服务器进入SYN_RECV状态； - 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(
ACK=1,ack=y+1,seq=x+1),此包发送完毕，客户端和服务器端进入established状态，完成三次握手.
问题
问题1：为什么需要三次握手才能建立起连接
为了初始化通信双方sequence number（同步序列编号）的初始值
问题2：server收到client的syn，并且回复syn-ack后，未收到client发送的ack确认，会有什么问题？
此时连接并未完成，处理“半连接”状态，server端接下来会不断重发syn-ack报文到客户端，重试5次后才关闭该半连接。
对于以上情况，可能会使服务器受到syn flood攻击：恶意程序发送syn请求然后下线了，此时服务端会维持一个半连接直到重试5次后才关闭（linux上重试的频率是1s后，2s后，4s后，...,32s后，一共会维持此连接63s才关闭），会占用服务端连接资源。
针对该攻击，linux采用syn cookie技术来避免：当syn队列满后，tcp会通过源地址端口/目标地址端口和时间戳生成特殊的sequence num（简称syn cookie）发回去，如果是正常连接，则clinet会回发syn cookie，直接建立连接。通过syn cookie技术，即使当前syn队列满了，本次连接请求不在syn队列中，也依旧能建立连接，进而解决了该问题的发生。
问题3：建议连接后，client出现故障怎么办？
tcp设有保活机制，在保活时间内，连接处于非活动状态，开启保活功能的一方将向对方发送保活探测报文，如果发送方未收到响应则继续发送。若在重发次数达到保活探测数后若仍未收到响应，则认为对方主机不可达，中断连接。
TCP四次挥手
tcp采用四次挥手来释放连接，
问题2：为什么需要四次挥手才能断开连接？
因为是全双工连接，发送方和接收方都需要FIN报文和ACK报文。
问题3：服务器出现大量CLOSE_WAIT状态的原因？
对方关闭socket连接，我方忙于读或写，没有及时关闭连接。解决办法如下：
- 第一次挥手：client发送一个FIN，用来关闭client到server的数据传送，client进入FIN_WAIT_1状态；
- 第二次挥手：server收到FIN后，发送一个ACK给client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）,server进入CLOSE_WAIT状态；
- 第三次挥手：server发送一个FIN，用来关闭server到client的数据传送，server进入LAST_ACK状态；
- 第四次挥手：client收到FIN后，client进入TIME_WAIT状态，接着发送一个ACK给server，确认序号为收到序号+1,server进入CLOSE状态，client等待2MSL（最长报文段寿命）时间后进入CLOSE状态，完成四次挥手。
问题
问题1：client不是立即关闭，而是等待2MSL后关闭？
- 确保有足够的时候让对方收到ACK包，如果被动关闭的那一方没有收到ACK包，就会触发被动关闭的端重发FIN包，一来一去所用的时间就是2MSL；
- 避免新旧连接混淆。有的路由器会缓存ip数据包，如果连接被重用了，那么这些延迟收到的包就可能会跟新的连接混在一起。
- 检查代码，特别是释放资源的代码
- 检查配置，特别是处理请求的线程配置
滑动窗口两个概念
- RTT：发送一个数据包到收到对应的ACK，所花费的时间
- RTO：重传时间间隔，即多久时间内没收到数据包对应的ACK，则再次发送该数据包
tcp的滑动窗口
tcp使用滑动窗口做流量控制与乱序重排，主要功能有如下两点：
- 保证tcp的可靠性
- 保证tcp的流量控制特性
tcp发送方滑动窗口发送数据过程如下：
发送的数据主要分为四类：
- 已发送并已收到ACK包
- 已发送但未收到ACK包
- 未发送但可以发送（准备发磅）
- 未发送且不可以发送（超过了窗口的大小）
其中，第2和第3加起来的报文长度就是发送窗口大小了。
tcp接收方滑动窗口接收数据过程如下：
与发送方类似，接收方的数据分为以下3类：
- 已接收并且已经返回ACK包
- 未接收但可以接收（准备接收）
- 未接收且不可以接收（超过了窗口的大小）
其中，第2部分的报文长度就是发送窗口大小。
接收窗口只有在前面所有的段都确认的情况下，才会移动左边界，当前面还有字节未接收但收到后面的字节时，窗口并不会移动，不会对后续字节进行确认，以确保对端会对未接收的数据进行重传。
总结：tcp传输可靠性来源于确认重传机制，tcp滑动窗口的可靠性也是建立在确认重传机制上的。
udp协议
相比于tcp而言，udp的报文简单太多了。udp的特点如下：
- 面向非连接
- 不维护连接状态，支持同时向鑫个客户羰传输相同的消息
- 数据包报头有8个字节，额外开销较小
- 吞吐量只受限于数据生成速率/传输速率以及机器性能
- 尽最大努力将会，不保证可靠交付，不需要维持复杂的链接状态表
- 面向报文，不对应用程序提交的报文信息进行拆分或者合并
tcp与udp的区别
- 面向连接 vs 面向无连接
- 可靠性：tcp保证传输的可靠性，而udp并不保证
- 有序性：tcp利用seq保证报文的有序性，而udp并不保证有序
- 速度：tcp面向连接，传输数据需要进行三次握手，需要做许多额外的工作，而udp则不需要
- 量级：tcp是重量级的，udp是轻量级的，主要体现在tcp头部占用20个字节，udp头部占用8个字节