网络分层

OSI七层模型

七层模型的结构清晰，每一层该干什么事。降低复杂性，统一标准，模块化。

物理层：很重要的一层，最底层，就像一个地基。保证双向传输，双向通讯。
数据链路层：①提供MAC地址；②负责数据帧的转发；③提供错误检查机制（交换机会对数据进行检测，如果发现有丢失，就会通知发送方重传数据）
网络层：①提供IP地址；②连接不同的媒介类型；③根据路由器运行的不同选择最佳路径；④在选择好的路径上路由数据包
传输层：传输层提供了端口号的概念。建立端口到端口的通信
会话层：在用于程序之间建立并维护会话连接
表示层：负责数据加密。比如对称加密、非对称加密…
应用层：给用户提供一个接口，用户可以通过用于程序来使用6层模型

七层模型虽然结构清晰，但是比较复杂并且不怎么实用，运行效率偏低。于是四层模型出现了

OSI四层模型

应用层：提供两个终端设备上的应用程序信息交换的服务，定义消息交换的格式，将消息交给传输层传输

传输层：使用TCP和UDP协议对消息进行传输

网络层：给分组交换网上不同主机提供通信服务

物理层：使用物理手段将电脑等设备连接起来比如光纤线路

TCP和UDP

TCP(传输控制协议) 和 UDP(用户数据报协议 ) 这两个是 TCP/IP协议的核心，都属于传输层。这一层主要负责网络中主机的定位。其中TCP是面向连接，具有可靠的数据传输机制。在发送数据之前必须建立连接。保证数据不会丢失，按顺序抵达。UDP则是无连接，不关心数据是否被正确接受到，只管发送，是一种不可靠的协议。这两种协议中，因为TCP要保证可靠性，所以只支持一对一通信，而UDP可以同时和多个主机进行通信。TCP也是面向字节流的而UDP是面向报文的

TCP的三次握手机制

第一次握手: 客户端向服务端发送一个请求报文，也就是seq，这个时候客户端进入SYN-SENT阶段

第二次握手: 服务端收到这个报文后，就会将自己的SYN设置为1（SYN表示当前是否被连接），ACK也设置为1。同时生成一个初始序列号，发送给客户端，发送完成后自己进入SYN-RECEIVED状态

第三次握手: 客户端收到服务端刚刚发送的同意应答后，再向服务端发送一个确认的报文，客户端发送完成后进入ESTABLISHED状态，服务端收到这个应答后，并进行检查后，也进入ESTABLISHED状态。完成三次握手

是不是看着很复杂？一头雾水？我用几句话来总结一下。

A主机想向B主机通信，A告诉B主机通信请求，让B给自己一个序列号（完成一次握手）。B主机收到这个请求，表示确认(ACK设置为1)，然后给A一个序列号（二次握手）。A收到后表示确认，发送表示”收到”的报文，开始正式传输数据（三次握手）。

TCP的四次挥手

第一次挥手: 客户端向服务端发送释放连接请求，发送FIN报文，客户端状态变为FIN_WAIT_1。此时客户端仍然可以接收数据

第二次挥手: 服务端收到FIN报文后，会向客户端发送ACK应答报文，但是连接并不会立刻终止，因为可能有未完成的数据。此时服务端的状态为CLOSE_WAIT(等待关闭)，客户端进入FIN_WAIT_2

（如果这个时候服务端因为某些原因没有给客户端回应，那么客户端会永远处于FIN_WAIT_2这个状态）

第三次挥手: 当服务端已经把数据全部发送完成，就会给客户端发送一个FIN报文，通知客户端连接可以正常关闭。此时服务端进入LAST_ACK(最终确认)状态

第四次挥手: 客户端收到服务端的FIN报文，给服务端发送ACK应答报文，服务端收到ACK应答报文后，关闭连接。此时客户端状态为TIME_WAIT，同时等待2MSL（MSL：报文在传输过程中的最大生命周期。这里等待2倍的时间），如果等待期间没有再收到服务端的FIN报文，就会关闭连接，进入CLOSED状态。完成四次挥手。

为什么第四次挥手时，客户端要等待2MSL？

主要是确保服务端可以收到客户端发送的ACK应答报文，从而进入关闭状态。

试想一种情况，第四次挥手的时候，客户端给服务端发送ACK应答报文，发送完直接进入CLOSED状态，而不是TIME_WAIT。如果发送的ACK丢失了呢，这样服务端就收不到客户端的ACK应答，等待1MSL后，重发请求释放也发不过去，因为客户端已经进入CLOSED状态了。服务端就会一直处于LAST_ACK状态，无法正确释放。而让客户端等待2倍的MSL时间关闭，就算最后的ACK应答报文丢失了，服务端也可以重新发送释放请求并被正常接收。

建立连接只用了三次，为什么关闭连接需要四次？

建立连接的时候，将ACK和SYN放在了同一个报文内

关闭连接的时候，客户端关闭后，但也要继续接收数据。所以这里分了2发送ACK报文和FIN报文（先返回ACK表示进入关闭状态(此时可以接收)，FIN则完全关闭连接）

UDP的使用场景

UDP因为其自身对传输可靠性不高，延迟低，无连接等状态，所以适合实时场景。

网络直播
网络游戏
流媒体
移动通信

UDP一定比TCP快吗？

不一定。UDP虽然速度快，但是有一个非常头疼的难题，那就是丢包问题。相信肯定会有玩游戏的表示，我一梭子全打上了，他一滴血没掉！对于丢包，谁都不愿意碰到。但如果我们用UDP传输一个特别大的数据时，TCP会根据MSS大小进行分段传输，如果发生丢包，重新穿这个分段就可以了。UDP不会分段，如果发生丢包情况，重新上传整个数据。在这种情况下，UDP就比TCP效率低了