A. 网络分层管理TCP/IP分层管理：应用层，传输层，网络层，数据链路层。（1）应用层：应用层决定了向用户提供应用

TCP/IP分层管理（有层次的协议栈）：

应用层，传输层，网络层，数据链路层

应用层：

应用层决定了向用户提供应用服务时通信的活动，eg. FTP、HTTP、DNS；DNS 提供域名到 IP 地址之间的解析服务，支持双向查询。（包括七层模型中表示层、会话层）

传输层：

提供处于网络连接中的两台计算机之间的数据传输。通常有两种协议：TCP(Transmission Control Protocol，传输控制协议)和 UDP(User Data Protocol，用户数据报协议)。

UDP

只是数据的搬运工，不会对数据做任何拆分拼接等处理。UDP 协议适用于对实时性要求高的应用场景。顺序发，乱序收 UDP的特点：

UDP的首部开销小，只有8个字节，它比TCP的20个字节的首部要短;

UDP是面向报文的，只在应用层交下来的报文前增加了首部后就向下交付IP层；

无连接，UDP是无连接的，即通信时不需要创建连接（发送数据结束时也没有连接可以释放）所以减小了开销和发送数据前的时延；

无阻塞，UDP是无阻塞控制的，即使网络中存在阻塞，也不会影响发送端的发送频率;

不可靠，UDP采用最大努力交付，不保证可靠交付，因此主机不需要维护复杂的连接状态；（顺序以及准确性）

UDP支持一对一、一对多、多对一、多对多的交互通信;

UDP报文段结构：
UDP 报文段由首部和应用数据组成 UDP头部

两个十六位的端口号，分别为源端口(可选字段)和目标端口\
整个数据报文的长度
整个数据报文的检验和(IPv4 可选字段)，该字段用于发现头部信息和数据中的错误

TCP

a. 字节流服务： 在传输层(TCP 协议)把从应用层处收到的数据 (HTTP 请求报文)进行分割 为报文段，并在各个报文上打上标记序号及端口号后转发给网络层。有先后顺序。

b. 可靠： TCP 协议采用了三次握手。TCP 会严格控制传输的正确性，一旦有某一个数据对端没有收到，就会停止下来直到对端收到这个数据。

TCP可靠性的来源：

确认重传机制

传输过程，如果checkSum失败，丢包或者延时，客户端会重传

数据排序

TCP头中有专门的序号字段，标明当前序号及后续序号。

流量控制

TCP头中会标识双方能够发送接收的最大数据量。

拥塞控制

防止过多的数据注入网络中，这样就可以控制网络中的路由器和链路不会过载。
四个核心算法：
  1）慢启动
  2）拥塞避免
  3）快速重传
  4）快速恢复

慢启动的基本思想是，因为在发送方刚开始发送数据的时候，并不知道网络中的拥塞程度，所以先以较低的速率发送，进行试探，每次收到一个确认报文，就将发动窗口的⻓度加一，这样每个 RTT 时间后，发送窗口的⻓度就会加 倍。当发送窗口的大小达到一个阈值的时候就进入拥塞避免算法。

拥塞避免算法是为了避免可能发生的拥塞，将发送窗口的大小由每过一个 RTT 增⻓一倍，变为每过一个 RTT ⻓度只加一。这样将窗口的增⻓速率由指数增⻓，变为加法线性增⻓。

快速重传指的是，当发送方收到三个冗余的确认应答时，因为 TCP 使用的是累计确认的机制，所以很有可能是发生了报文段的 丢失，因此采用立即重传的机制，在定时器结束前发送所有已发送但还未接收到确认应答的报文段。

快速恢复是对快速重传的后续处理，因为网络中可能已经出现了拥塞情况，所以会将慢启动的阀值减小为原来的一半，然后将拥塞窗口的值置为减半后的阀值，然后开始执行拥塞避免算法，使得拥塞窗口缓慢地加性增大。简单来理解就是，乘性减，加性增。

TCP头部：

TCP头部一般20个字节。

Sequence number，这个序号保证了 TCP 传输的报文都是有序的，对端可以通过序号顺序的拼接报文;
Acknowledgement Number，这个序号表示数据接收端期望接收的下一个字节的编号是多少，同时也表示上一个序号的数据已经收到;
Window Size，窗口大小，表示还能接收多少字节的数据，用于流量控制;

标识符

SYN=1 连接请求、连接同意；当 SYN=1，ACK=0 时，表示当前报文段是一个连接请求报文。当 SYN=1，ACK=1 时，表示当前报文段是一个同意建立连接的应答报文。
ACK=1 确认号段有效，TCP规定建立连接后，所有报文ACK=1；
FIN=1 释放连接；
RST=1 该字段为一表示当前 TCP 连接出现严重问题，可能需要重新建立 TCP 连接，也可以拒绝连接请求或拒绝非法报文段；
性能指标RTT 性能指标 RTT。该指标表示发送端发送数据到接收到对端数据所需的往返时间；

三次握手

起初，两端都为 CLOSED 状态。在通信开始前，双方都会创建 TCB。服务器创建完 TCB 后便进入LISTEN状态，此时开始等待客户端发送数据。
第一次握手：客户端向服务端发送连接请求报文段。该报文段中包含自身的数据通讯初始序号。请求发送后，客户端便进入 SYN-SENT 状态。
第二次握手：服务端收到连接请求报文段后，如果同意连接，则会发送一个应答，该应答中也会包含自身的数据通讯初始序号，发送完成后便进入 SYN-RECEIVED 状态
第三次握手：当客户端收到连接同意的应答后，还要向服务端发送一个确认报文。客户端发完这个报文段后便进入 ESTABLISHED 状态，服务端收到这个应答后也进入 ESTABLISHED 状态，此时连接建立成功。

为什么 TCP 建立连接需要三次握手，明明两次就可以建立起连接?

为了防止出现失效的连接请求报文段被服务端接收的情况，从而产生错误;

客户端发送了一个连接请求 A，但是因为网络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送一个连接请求 B。此时请求顺利到达服务端，服务端应答完就建立了请求，然后接收数据后释放了连接。

假设这时候连接请求 A 在两端关闭后终于抵达了服务端，那么此时服务端会认为客户端又需要建立 TCP 连接，从而应答了该请求并进入 ESTABLISHED 状态。但是客户端其实是 CLOSED 的状态，那么就会导致服务端一直等待，造成资源的浪费。

PS:在建立连接中，任意一端掉线，TCP 都会重发 SYN 包，一般会重试五次，在建立连接中可能会遇到 SYN Flood 攻击。遇到这种情况你可以选择调低重试次数或者干脆在不能处理的情况下拒绝请求。

四次挥手

第一次握手 若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。
第二次握手 B 收到连接释放请求后，会告诉应用层要释放 TCP 链接。然后会发送 ACK 包，并进入 CLOSE_WAIT 状态，此时表明 A 到 B的连接已经释放，不再接收 A 发的数据了。但是因为 TCP 连接是双向的，所以 B 仍旧可以发送数据给 A。
第三次握手B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进入 LAST-ACK 状态。 PS:通过延迟确认的技术(通常有时间限制，否则对方会误认为需要重传)，可以将第二次和第三次握手合并，延迟 ACK 包的发送。
第四次握手 A 收到释放请求后，向 B 发送确认应答，此时 A 进入 TIME-WAIT 状态。该状态会持续 2MSL(最大段生存期，指报文段在网络中生存的时间，超时会被抛弃) 时间，若该时间段内没有 B 的重发请求的话，就进入 CLOSED 状态。当 B 收到确认应答后，也便进入 CLOSED 状态。

为什么 A 要进入 TIME-WAIT 状态，等待 2MSL 时间后才进入 CLOSED 状态?

客户端会等待一段时间再关闭的原因，是为了防止发送给服务器的确认报文段丢失或者出错，从而导致服务器端不能正常关闭。为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进入 CLOSED 状态，如果确认应答因为网络问题一直没有到达，那么会造成 B 不能正常关闭。