网络协议（一） TCP/IP 协议

1. TCP/IP 简介
- 1.1 TCP/IP 协议族
- 1.2 TCP/IP 的分层管理
- - 1.2.1 应用层
  - 1.2.2 传输层
  - - 1.2.2.1 传输层工作流程
  - 1.2.3 网络层
  - 1.2.4 链路层
  - - 1.2.4.1 链路层工作流程
    - 1.2.4.2 链路层协议
2 TCP/IP协议详解
- 2.1. TCP/IP协议数据封装
- 2.2. TCP/IP协议数据封装过程
- 2.3. TCP的三次握手（建立连接）和四次挥手（断开连接）
- - 2.3.1 TCP的三次握手
  - - 2.3.1.1 TCP的三次握手简介
    - 2.3.1.2 TCP的三次握手分析
  - 2.3.2 TCP的四次挥手
- 2.4. TCP确认应答机制(ACK机制)
- 2.5. TCP超时重传机制
- 2.6. TCP滑动窗口机制
- - 2.6.1 TCP滑动窗口机制流程
- 2.7. TCP流量控制
- - 2.7.1 什么是流量控制
  - 2.7.2 流量控制流程
- 2.8. TCP拥塞控制
- - 2.8.1 拥塞窗口
3.UDP协议
- 3.1 TCP，UDP区别
- 3.2 UDP协议简介
4 IP协议
- 4.1 IP 包数据格式

1. TCP/IP 简介

TCP (Transmission Control Protocol)和UDP(User Datagram Protocol)协议属于传输层协议。其中TCP提供IP环境下的数据可靠传输，它提供的服务包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。通俗说，它是事先为所发送的数据开辟出连接好的通道，然后再进行数据发送；而UDP则不为IP提供可靠性、流控或差错恢复功能。一般来说，TCP对应的是可靠性要求高的应用，而UDP对应的则是可靠性要求低、传输经济的应用。TCP支持的应用协议主要有：Telnet、FTP、SMTP等；UDP支持的应用层协议主要有：NFS（网络文件系统）、SNMP（简单网络管理协议）、DNS（主域名称系统）、TFTP（通用文件传输协议）等.
TCP/IP协议与低层的数据链路层和物理层无关，这也是TCP/IP的重要特点

1.1 TCP/IP 协议族

计算机与网络设备要相互通信，双方就必须基于相同的方法。比如，如何探测到通信目标、由哪一边先发起通信、使用哪种语言进行通信、怎样结束通信等规则都需要事先确定。不同的硬件、操作系统之间的通信，所有的这一切都需要一种规则。而我们就把这种规则称为协议(protocol)。

协议中存在各式各样的内容。从电缆的规格到 IP 地址的选定方法、寻找异地用户的方法、双方建立通信的顺序，以及 Web 页面显示需要处理的步骤，等等。
像这样把与互联网相关联的协议集合起来总称为 TCP/IP。也有说法认为，TCP/IP 是指 TCP 和 IP 这两种协
议。还有一种说法认为，TCP/ IP 是在 IP 协议的通信过程中，使用到的协议族的统称。

1.2 TCP/IP 的分层管理

当通过http发起一个请求时，应用层、传输层、网络层和链路层的相关协议依次对该请求进行包装并携带对应的首部，最终在链路层生成以太网数据包，以太网数据包通过物理介质传输给对方主机，对方接收到数据包以后，然后再一层一层采用对应的协议进行拆包，最后把应用层数据交给应用程序处理。
网络通信就好比送快递，商品外面的一层层包裹就是各种协议，协议包含了商品信息、收货地址、收件人、联系方式等，然后还需要配送车、配送站、快递员，商品才能最终到达用户手中。
一般情况下，快递是不能直达的，需要先转发到对应的配送站，然后由配送站再进行派件。
配送车就是物理介质，配送站就是网关，快递员就是路由器，收货地址就是IP地址，联系方式就是MAC地址。
快递员负责把包裹转发到各个配送站，配送站根据收获地址里的省市区，确认是否需要继续转发到其他配送站，当包裹到达了目标配送站以后，配送站再根据联系方式找到收件人进行派件。
有了整体概念以后，下面我们详细了解一下各层的分工。

1.2.1 应用层

应用层职责：定义数据格式，并按照对应的格式解读数据。
应用层决定了向用户提供应用服务时通信的活动。
TCP/IP 协议族内预存了各类通用的应用服务。比如，FTP(File Transfer Protocol，文件传输协议)和 DNS(Domain Name System，域名系统)服务就是其中两类。
HTTP 协议也处于该层。

1.2.2 传输层

传输层职责：定义端口，确认主机上应用程序的身份，并将数据包交给对应的应用程序。
传输层对上层应用层，提供处于网络连接中的两台计算机之间的数据传输。传输层的主要工作是定义端口，标识应用程序身份，实现端口到端口的通信，TCP协议可以保证数据传输的可靠性。
在传输层有两个性质不同的协议:TCP(Transmission Control Protocol，传输控制协议)和 UDP(User Data Protocol，用户数据报协议)。

TCP为两台主机提供高可靠性的数据通信。它所做的工作包括把应用程序交给它的数据分成合适的小块交给下面的网络层，确认接收到的分组，设置发送最后确认分组的超时时钟等。由于运输层提供了高可靠性的端到端的通信，因此应用层可以忽略所有这些细节。为了提供可靠的服务，TCP采用了超时重传、发送和接收端到端的确认分组等机制。

UDP则为应用层提供一种非常简单的服务。它只是把称作数据报的分组从一台主机发送到另一台主机，但并不保证该数据报能到达另一端。一个数据报是指从发送方传输到接收方的一个信息单元（例如，发送方指定的一定字节数的信息）。UDP协议任何必需的可靠性必须由应用层来提供。

1.2.2.1 传输层工作流程

链路层定义了主机的身份，即MAC地址，而网络层定义了IP地址，明确了主机所在的网段，有了这两个地址，数据包就从可以从一个主机发送到另一台主机。但实际上数据包是从一个主机的某个应用程序发出，然后由对方主机的应用程序接收。而每台电脑都有可能同时运行着很多个应用程序，所以当数据包被发送到主机上以后，是无法确定哪个应用程序要接收这个包。
因此传输层引入了UDP协议来解决这个问题，为了给每个应用程序标识身份，UDP协议定义了端口，同一个主机上的每个应用程序都需要指定唯一的端口号，并且规定网络中传输的数据包必须加上端口信息。这样，当数据包到达主机以后，就可以根据端口号找到对应的应用程序了。UDP定义的数据包就叫做UDP数据包，结构如下所示：
UDP数据包由首部和数据两部分组成，首部长度为8个字节，主要包括源端口和目标端口；数据最大为65527个字节，整个数据包的长度最大可达到65535个字节。
UDP协议比较简单，实现容易，但它没有确认机制，数据包一旦发出，无法知道对方是否收到，因此可靠性较差，为了解决这个问题，提高网络可靠性，TCP协议就诞生了，TCP即传输控制协议，是一种面向连接的、可靠的、基于字节流的通信协议。简单来说TCP就是有确认机制的UDP协议，每发出一个数据包都要求确认，如果有一个数据包丢失，就收不到确认，发送方就必须重发这个数据包。
为了保证传输的可靠性，TCP 协议在 UDP 基础之上建立了三次对话的确认机制，也就是说，在正式收发数据前，必须和对方建立可靠的连接。具体详情后面会详细讲解。
TCP 数据包和 UDP 一样，都是由首部和数据两部分组成，唯一不同的是，TCP 数据包没有长度限制，理论上可以无限长，但是为了保证网络的效率，通常 TCP 数据包的长度不会超过IP数据包的长度，以确保单个 TCP 数据包不必再分割。

1.2.3 网络层

网络层职责：定义IP地址，确认主机所在的网络位置，并通过IP进行MAC寻址，对外网数据包进行路由转发。
网络层用来处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径 (所谓的传输路线)到达对方计算机，并把数据包传送给对方。
与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
网络层协议包括:IP协议（网际协议），ICMP协议（Internet互联网控制报文协议），以及IGMP协议（Internet组管理协议）。

IP数据包:在网络层被包装的数据包就叫IP数据包，IPv4数据包的结构如下图所示:

IP数据包由首部和数据两部分组成，首部长度为20个字节，主要包含了目标IP地址和源IP地址，目标IP地址是网关路由的线索和依据；数据部分的最大长度为65515字节，理论上一个IP数据包的总长度可以达到65535个字节，而以太网数据包的最大长度是1500个字符，如果超过这个大小，就需要对IP数据包进行分割，分成多帧发送。
所以，网络层的主要工作是:定义网络地址，区分网段，子网内MAC寻址，对于不同子网的数据包进行路由。
IP协议：是一种网络层协议，提供的是一种不可靠的服务，它只是尽可能快地把分组从源结点送到目的结点，但是并不提供任何可靠性保证。同时被TCP和UDP使用。TCP和UDP的每组数据都通过端系统和每个中间路由器中的IP层在互联网中进行传输。

IP地址目前有两个版本，分别是IPv4和IPv6，IPv4是一个32位的地址，常采用4个十进制数字表示。IP协议将这个32位的地址分为两部分，前面部分代表网络地址，后面部分表示该主机在局域网中的地址。由于各类地址的分法不尽相同，以C类地址192.168.24.1为例，其中前24位就是网络地址，后8位就是主机地址。因此，如果两个IP地址在同一个子网内，则网络地址一定相同。为了判断IP地址中的网络地址，IP协议还引入了子网掩码， IP地址和子网掩码通过按位与运算后就可以得到网络地址。
由于发送者和接收者的IP地址是已知的(应用层的协议会传入)，因此我们只要通过子网掩码对两个IP地址进行AND运算后就能够判断双方是否在同一个子网了。

ICMP协议(互联网控制报文协议)：是IP协议的附属协议。IP层用它来与其他主机或路由器交换错误报文和其他重要信息。

ICMP的一个方式就是差错报文类型，另一个是查询报文类型ping命令。
从TYPE角度来看，终点不可达为3，源主机抑制为4（目标主动停止），超时为11（生命周期SST用完了）。这样就知道当前怎么回事了。CODE是更加详细的问题描述，0代表网络不可达，1代表主机不可达等等。

IGMP协议：是Internet组管理协议。它用来把一个UDP数据报多播到多个主机。
路由协议:ARP的MAC寻址还是局限在同一个子网中，因此网络层引入了路由协议，首先通过IP协议来判断两台主机是否在同一个子网中，如果在同一个子网，就通过ARP协议查询对应的MAC地址，然后以广播的形式向该子网内的主机发送数据包；如果不在同一个子网，以太网会将该数据包转发给本子网的网关进行路由。网关是互联网上子网与子网之间的桥梁，所以网关会进行多次转发，最终将该数据包转发到目标IP所在的子网中，然后再通过ARP获取目标机MAC，最终也是通过广播形式将数据包发送给接收方。
而完成这个路由协议的物理设备就是路由器，在错综复杂的网络世界里，路由器扮演者交通枢纽的角色，它会根据信道情况，选择并设定路由，以最佳路径来转发数据包。
流程图如下：
DHCP协议（动态路由协议）:
日常生活中，我们都是插上网线就可以用了，并没有配置IP啊。那么这个过程就会使用到了DHCP协议，由DHCP服务器管理了IP的分配，并分给刚来的网卡一个可用的IP。
简单说DHCP就是负责管理IP地址的，简单。不过我所在的公司为了可控都是采用静态IP的。需要管理员分配IP并配置。
- DHCP工作工程：

想想一个刚来的电脑怎么才能和DHCP服务器联系了，毕竟它什么也不知道，这时候广播地址就派上用场了。新的电脑就会使用0.0.0.0这个IP地址，目的IP为255.255.255.255.源端口为68，目标端口为67，发送一个UDP的广播。这样DHCP服务器收到了，就知道新来了一个电脑需要IP，服务器就选择一个IP，也是通过广播的方式发送IP、子网掩码、网关等相关信息。这样新的电脑会收到了一个IP地址，但是如果要是多个DHCP发送了多个IP了？新的电脑会选择一个IP，继续发送广播包，告诉DHCP服务器，自己所选用的IP号和一些其他信息，当然DHCP服务器收到了广播后，会返回给新电脑一个ACK确认包，这样一次完整的DHCP过程才算结束。
DHCP服务器会不仅可以动态分配IP，还可以回收IP，正所谓有借有还再借不难嘛，DHCP服务器会在租期时间结束的时候自动的回收IP该IP。但如果网卡的IP还要用该怎么办了？客户端租期时间过去的时候就重新向服务器发送请求，客户端收到服务器的返回后，就会更新新的租赁参数。

1.2.4 链路层

链路层职责：对0和1进行分组，定义数据帧，确认主机的物理地址，传输数据。
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC(Network Interface Card，网络适配器，即网卡)，及光纤等物理可见部分(还包括连接器等一切传输媒介)。硬件上的范畴均在链路层的作用范围之内。在链路层，ARP（地址解析协议）和RARP（逆地址解析协议）是某些网络接口（如以太网和令牌环网）使用的特殊协议，用来转换IP层和网络接口层使用的地址。

1.2.4.1 链路层工作流程

网络通信就是把有特定意义的数据通过物理介质传送给对方，单纯的发送 0 和 1 是没有意义的，要传输有意义的数据，就需要以字节为单位对 0 和 1 进行分组，并且要标识好每一组电信号的信息特征，然后按照分组的顺序依次发送。以太网规定一组电信号就是一个数据包，一个数据包被称为一帧，制定这个规则的协议就是以太网协议。一个完整的以太网数据包如下图所示：

整个数据帧由首部、数据和尾部三部分组成，首部固定为14个字节，包含了目标MAC地址、源MAC地址和类型；数据最短为46个字节，最长为1500个字节，如果需要传输的数据很长，就必须分割成多个帧进行发送；尾部固定为4个字节，表示数据帧校验序列，用于确定数据包在传输过程中是否损坏。因此，以太网协议通过对电信号进行分组并形成数据帧，然后通过物理介质把数据帧发送给接收方。那么以太网如何来识接收方的身份呢？
以太网规协议定，接入网络的设备都必须安装网络适配器，即网卡，数据包必须是从一块网卡传送到另一块网卡。而网卡地址就是数据包的发送地址和接收地址，也就是帧首部所包含的MAC地址，MAC地址是每块网卡的身份标识，就如同我们身份证上的身份证号码，具有全球唯一性。MAC地址采用十六进制标识，共6个字节，前三个字节是厂商编号，后三个字节是网卡流水号，例如 4C-0F-6E-12-D2-19
有了MAC地址以后，以太网采用广播形式，把数据包发给该子网内所有主机，子网内每台主机在接收到这个包以后，都会读取首部里的目标MAC地址，然后和自己的MAC地址进行对比，如果相同就做下一步处理，如果不同，就丢弃这个包。
所以链路层的主要工作就是对电信号进行分组并形成具有特定意义的数据帧，然后以广播的形式通过物理介质发送给接收方。

1.2.4.2 链路层协议

ARP协议:地址解析协议，是根据IP地址获取MAC地址的一个网络层协议。
其工作原理如下：

ARP首先会发起一个请求数据包，数据包的首部包含了目标主机的IP地址，然后这个数据包会在链路层进行再次包装，生成以太网数据包，最终由以太网广播给子网内的所有主机，每一台主机都会接收到这个数据包，并取出标头里的IP地址，然后和自己的IP地址进行比较，如果相同就返回自己的MAC地址，如果不同就丢弃该数据包。ARP接收返回消息，以此确定目标机的MAC地址；与此同时，ARP还会将返回的MAC地址与对应的IP地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。cmd输入 arp -a 就可以查询本机缓存的ARP数据。

ARP工作原理图如下：

2 TCP/IP协议详解

2.1. TCP/IP协议数据封装

TCP/IP每一层都让数据得以通过网络进行传输，这些层之间使用PDU（协议数据单元）彼此交换信息，确保网络设备之间能够通信

A. 传输层数据中加入TCP报头后得到PDU被称为segment（数据段）；
B. 数据段被传递给网络层，网络层添加IP报头得到的PDU被称为packet（数据包）；
C. 数据包被传递到数据链路层，封装数据链路层报头得到的PDU被称为frame（数据帧）；
D. 帧被转换为比特，通过网络介质传输。

这种协议栈向下传递数据，并添加报头和报尾的过程称为封装，数据被封装并通过网络传输后，接收设备将删除添加的信息，并根据报头中的信息决定如何将数据沿协议栈上传给合适的应用程序，这个过程称为解封装。不同设备的对等层之间依靠封装和解封装来实现相互间的通信。

2.2. TCP/IP协议数据封装过程

先看一张图如下：

以传输层采用TCP或者UPD、网络层采用IP、链路层采用Ethernet为例，可以看到TCP/IP中报文的封装过程如上图所示。用户数据经过应用层协议封装后传递给传输层，传输层封装TCP头部，交给网络层，网络层封装IP头部后，再交给数据链路层，数据链路层封装Ethernet帧头和帧尾，交给物理层，物理层以比特流的形式将数据发送到物理线路上。

当目的主机收到一个以太网数据帧时，数据就开始从协议栈中由底向上升，同时去掉各层协议加上的报文首部。每层协议盒都要去检查报文首部中的协议标识，以确定接收数据的上层协议。这个过程称作分用（Demultiplexing）。协议是通过目的端口号、源I P地址和源端口号进行解包的。

TCP数据包格式
TCP首部格式

上面图TCP数据包字段简介
TCP使用IP作为网络层协议，TCP数据段被封装在一个IP数据包内。TCP数据段由TCP Head（头部）和TCP Data（数据）组成。

TCP最多有60个字节的首部,如果没有任选字段，正常的长度是20字节。TCP Head如上图标识的一些字段组成，这里列出几个常用的字段。

字段	功能	备注
16位源端口号	TCP会为源应用程序分配一个源端口号	-
16位目的端口号	目的应用程序的端口号。每个TCP段都包含源和目的端的端口号，用于寻找发端和收端应用进程。这两个值加上IP首部中的源端IP地址和目的端IP地址可以唯一确定一个TCP连接。	备注
32位序列号	用于标识从TCP发端向TCP收端发送的数据字节流。	-
32位确认序列号	确认序列号包含发送确认的一端所期望收到的下一个序号。确认序列号为上次成功收到的数据序列号加1。	-
4位首部长度	表示首部占32bit字的数目。因为TCP首部的最大长度为60字节	备注
16位窗口大小	表示接收端期望接收的字节，由于该字段为16位，因而窗口大小最大值为65535字节。	-
16位检验和	检验和覆盖了整个TCP报文段，包括TCP首部和TCP数据。该值由发端计算和存储并由接收端进行验证	-

6位标志位

字段	功能	备注
UNG标志	表示紧急指针是否有效
ACK标志	表示确认号是否有效。我们将携带ACK标志的TCP报文段为确认报文段
PSH标志	提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间
RST标志	表示要求对方重新建立连接。我们将携带RST标志的TCP报文段为复位报文段
SYN标志	表示请求建立一个连接。我们将携带SYN标志的TCP报文段为同步报文段
FIN标志	表示通知对方本端要关闭连接了。我们将携带FIN标志的TCP报文段为结束报文段

2.3. TCP的三次握手（建立连接）和四次挥手（断开连接）

2.3.1 TCP的三次握手

2.3.1.1 TCP的三次握手简介

如上图，我们可以清楚的看到三次握手的过程，具体握手流程如下：

第一次:
客户端 - - > 服务器此时服务器知道了客户端要建立连接了
第二次:
客户端 < - - 服务器此时客户端知道服务器收到连接请求了
第三次:
客户端 - - > 服务器此时服务器知道客户端收到了自己的回应
到这里, 就可以认为客户端与服务器已经建立了连接.

为了更加清楚的弄清过程可以再看一下这张动态图：

图里面的SYN，ACK，PSH，FIN，RST，URG 就是前面已经解释过的TCP包首部格式中的6位标志位。

字段	功能	备注
UNG标志	表示紧急指针是否有效
ACK标志	表示确认号是否有效。我们将携带ACK标志的TCP报文段为确认报文段
PSH标志	提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空间
RST标志	表示要求对方重新建立连接。我们将携带RST标志的TCP报文段为复位报文段
SYN标志	表示请求建立一个连接。我们将携带SYN标志的TCP报文段为同步报文段
FIN标志	表示通知对方本端要关闭连接了。我们将携带FIN标志的TCP报文段为结束报文段
Sequence number	Seq序号，占32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
Acknowledge number	Ack序号，占32位，只有ACK标志位为1时，确认序号字段才有效，Ack=Seq+1

2.3.1.2 TCP的三次握手分析

如上图中我们可以大致看到3次握手的过程：

刚开始, 客户端和服务器都处于 CLOSE 状态. 此时, 客户端向服务器主动发出连接请求, 服务器被动接受连接请求.
TCP服务器进程先创建传输控制块TCB, 时刻准备接受客户端进程的连接请求, 此时服务器就进入了 LISTEN（监听）状态。
TCP客户端进程也是先创建传输控制块TCB, 然后向服务器发出连接请求报文，此时报文首部中的同步标志位SYN=1, 同时选择一个初始序列号 seq = x, 此时，TCP客户端进程进入了 SYN-SENT（同步已发送状态）状态。TCP规定, SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。
TCP服务器收到请求报文后, 如果同意连接, 则发出确认报文。确认报文中的 ACK=1, SYN=1, 确认序号是 x+1, 同时也要为自己初始化一个序列号 seq = y, 此时, TCP服务器进程进入了SYN-RCVD（同步收到）状态。这个报文也不能携带数据, 但是同样要消耗一个序号。
TCP客户端进程收到确认后还, 要向服务器给出确认。确认报文的ACK=1，确认序号是 y+1，自己的序列号是 x+1.
此时，TCP连接建立，客户端进入ESTABLISHED（已建立连接）状态。当服务器收到客户端的确认后也进入ESTABLISHED状态，此后双方就可以开始通信了。

这里很多人肯定有疑问，为啥是三次，不是两次或者四次呢？

为啥不用两次？

答：主要是为了防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送的第一个请求连接并且没有丢失，只是因为在网络中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时之前滞留的那一次请求连接，因为网络通畅了, 到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为啥不用四次？

答：这个很好解释，因为三次已经可以满足需要了, 四次就多余了.属于浪费资源。

2.3.2 TCP的四次挥手

下来看四次挥手的一个时序图：

我们先来分析一下上图的四次握手的过程：

数据传输完毕后，双方都可以释放连接. 此时客户端和服务器都是处于ESTABLISHED状态，然后客户端主动断开连接，服务器被动断开连接.
客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
服务器收到连接释放报文，发出确认报文，ACK=1，确认序号为 u+1，并且带上自己的序列号seq=v，此时服务端就进入了CLOSE-WAIT（关闭等待）状态。 TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
客户端收到服务器的确认请求后，此时客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最终数据）
服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，确认序号为v+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，确认序号为w+1，而自己的序列号是u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

通过一张动态图来加深理解：

说白了整个建立连接三次握手过程就像这样的场景：
(1). 一男一女在一个咖啡厅相亲，男的（客户端）先问：你觉得我怎么样？（第一次握手）
(2). 女的回答：我觉得你很帅 然后问了男的一句：你觉得我漂亮么？，想确认一下男方的意见。（第二次握手）
(3). 男的听到女的回答心里早就乐开了花，巴不得马上牵着女方的小手，回答：我觉得你就是我的女神，我们在一起吧 ，到此牵手成功。（第三次握手）建立连接。
(4). 如果上面3步少了任何一步都不能牵手，要两个人都同意，都确认后才能建立连接。

而四次挥手的过程，就类似于这样的场景：
(1). 相亲的男女在一起相处了一阵子，开始闹矛盾了，女的性子比较急一点，先提出分手（女方相当于客户端）女的说：我受够你了，你就是个矮矬穷，我要的白马王子应该是高富帅才对。（第一次挥手：FIN M）第一次挥手后进入了 Finish_Wait_1状态
(2). 男的觉得女的还挺好的，很漂亮，就是性格有点倔强，不想分手，男的还想给女的说很多话去挽留。此时男的说：我收到你要分手的信息了 （ack+1）,然后又向女的说了很多挽留的话，此时只有男的向女的说话（服务器–》客户端）半双工。(第二次挥手: ack M+1) （服务器收到第一次挥手的信息后，就进入Close_Wait状态，但是还可以像客户端继续发送没有发送完的信息，然后发送一个确认包：ack = M+1）
(3). 男的思考了很近说了很多话挽留都无效，然后男绝望的说了一句：真的要分手吗 再次确认一下（FIN N）然后等待女方的回答，不再向女方说话了。（第三次挥手）(此时服务器进入了LAST_ACK最后确认状态)

(4). 女的听到男的说的话之后, 有些犹豫了，如果她想反悔了，就可以跟男的说：我不想分手了 这样分手就失败了，如果她还是坚持她自己原生相反，坚决要分手，她就会说：我想了很久，我们真的不合适，我们还是分手吧 （第四次挥手：ACK=1, ack = K +1 ）。（此时客户端进入Time_Wait状态，等待一个2MSL时间就会关闭连接）
(5). 男方收到女方的信息，如果男方决定要分手，就会直接Close()关闭通话状态，不必再发信息给女方了，如果男方决定不分手了，就会再跟女的说：我们不分手了到此分手就已失败结束了。（这里服务器会比客户端先关闭连接状态，客户端需要等待一个最长2MSL的时间）

为什么最后客户端还要等待 2*MSL的时间呢?

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。

第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。

第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

为什么是三次握手，两次可以吗？

解答：首先，两次显然是不可以的。这类问题可以举一个反例来说明情况。谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 server。本来这是一个早已失效的报文段。但 server 收到此失效的连接请求报文段后，就误认为是 client 再次发出的一个新的连接请求。于是就向 client 发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要 server 发出确认，新的连接就建立了。由于现在 client 并没有发出建立连接的请求，因此不会理睬 server 的确认，也不会向 server 发送数据。但 server 却以为新的运输连接已经建立，并一直等待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况， client 不会向 server 的确认发出确认。server 由于收不到确认，就知道 client 并没有要求建立连接。”。主要目的防止 server 端一直等待，浪费资源。扩展下，挥手一般是四次为什么？挥手在某些情况下三次能完成吗？某些情况下，三次是可以完成挥手的，当本端关闭了连接，恰好也同时收到了对方的 FIN 报文，此时可以把自己的 FIN 和给对端的确认 ACK 合在一起发送。就变成了三次。

为什么建立连接是三次握手，关闭连接确是四次挥手呢？

1.建立连接的时候，服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

2.关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

答：虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。

三次握手的作用是?

1）使得通讯双发都做好通讯的准备
2）告诉对端本端通讯所选用的报文标识号
3）防止已失效的连接请求报文段又突然传递到了服务端，从而产生错误

三次握手那个阶段容易出现攻击？

解答：比较典型的是 syn 泛洪攻击，或叫 syn 溢出攻击。 syn 溢出攻击，即出现在第二个阶段，如果客户机伪造出大量第一次的 sys 同步报文，服务端就会依次耗掉很多资源来保存客户端的信息，并进行确认，实际确认是会失败的，但失败是需要一定时间，因为服务端会连续多次进行第二次握手确认后才认定失败。那么短时间有大量 syn 同步报文涌向服务端，服务器资源可能被耗尽，就可能导致正常的客户端得不到响应而失败。

三次握手那个阶段会出现异常？

解答：第二个阶段可能异常，如果服务器相应的端口未打开，会回复 RST 复位报文，握手失败。此外，listen 创建的监听队列达到上限，也可能失败。

TIME_WAIT 和 CLOSE_WAIT 有什么区别？

解答： CLOSE_WAIT 是被动关闭的一端在接收到对端关闭请求（FIN 报文段）并且将 ACK 发送出去后所处的状态，这种状态表示：收到了对端关闭的请求，但是本端还没有完成工作，还未关闭。 TIME_WAIT 状态是主动关闭的一端在本端已经关闭的前期下，收到对端的关闭请求（FIN 报文段）并且将 ACK 发送出去后所处的状态，这种状态表示：双方都已经完成工作，只是为了确保迟来的数据报能被是被并丢弃，可靠的终止 TCP 连接。

TIME_WAIT 状态存在的意义？

解答： TIME_WAIT 状态是：主动断开连接的一端收到对端的 FIN 报文段并且将 ACK 报文段发出后的一种状态。
意义：
1）保证迟来的报文段能被识别并丢弃。
2）保证可靠的终止 TCP 连接。保证对端能收到最后的一个 ACK，如果 ACK 丢失，在TIME_WAIT状态本端还可以接受到对端重传的FIN报文段并重新发送ACK。所以 TIME_WAIT 的存在时间为 2MSL。

如果已经建立了连接, 但是客户端突发故障了怎么办?

TCP设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

2.4. TCP确认应答机制(ACK机制)

TCP将每个字节的数据都进行了编号, 即为序列号.
每一个ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你要从哪里开始发. 比如, 客户端向服务器发送了1005字节的数据, 服务器返回给客户端的确认序号是1003, 那么说明服务器只收到了1-1002的数据.
1003, 1004, 1005都没收到.
此时客户端就会从1003开始重发.

2.5. TCP超时重传机制

主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
但是主机A没收到确认应答也可能是ACK丢失了.

这种情况下, 主机B会收到很多重复数据.
那么TCP协议需要识别出哪些包是重复的, 并且把重复的丢弃.
这时候利用前面提到的序列号, 就可以很容易做到去重.
超时时间如何确定?
最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”. 但是这个时间的长短, 随着网络环境的不同, 是有差异的. 如果超时时间设的太长, 会影响整体的重传效率; 如果超时时间设的太短, 有可能会频繁发送重复的包.
TCP为了保证任何环境下都能保持较高性能的通信, 因此会动态计算这个最大超时时间.

Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传. 如果仍然得不到应答, 等待 4500ms 进行重传.
依次类推, 以指数形式递增. 累计到一定的重传次数, TCP认为网络异常或者对端主机出现异常, 强制关闭连接.

2.6. TCP滑动窗口机制

先看下面一张图：

TCP滑动窗口技术通过动态改变窗口大小来调节两台主机间的数据传输。每个TCP/IP主机支持全双工数据传输，因此TCP有两个滑动窗口：一个用于接收数据，另一个用于发送数据。TCP使用肯定确认技术，其确认号指的是下一个所期待的字节。
如图中所示以数据单方向发送为例，介绍滑动窗口如何实现流量控制。服务器端向客户端发送4个大小为1024字节的数据段，其中发送端的窗口大小为4096，客户端到以ACK4097响应，窗口大小调整为2048，表明客户端（即接收端）缓冲区只能处理2048个字节的数据段。于是发送端改变其发送速率。发送接收端能够接收的数据段大小2048的数据段。

滑动窗口

窗口大小指的是无需等待确认应答就可以继续发送数据的最大值.
上图的窗口大小就是4000个字节 (四个段).
发送前四个段的时候, 不需要等待任何ACK, 直接发送
收到第一个ACK确认应答后, 窗口向后移动, 继续发送第五六七八段的数据…
因为这个窗口不断向后滑动, 所以叫做滑动窗口.
操作系统内核为了维护这个滑动窗口, 需要开辟发送缓冲区来记录当前还有哪些数据没有应答
只有ACK确认应答过的数据, 才能从缓冲区删掉.

如果出现了丢包, 那么该如何进行重传呢?
此时分两种情况讨论:
- 1, 数据包已经收到, 但确认应答ACK丢了. 这种情况下, 部分ACK丢失并无大碍, 因为还可以通过后续的ACK来确认对方已经收到了哪些数据包.
- 2, 数据包丢失 . 如下图：当某一段报文丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 “我想要的是 1001”
  如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送
  这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了
  因为2001 - 7000接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中.

2.6.1 TCP滑动窗口机制流程

发送端滑动窗口：首先滑动窗口机制解决了数据包的顺序问题、丢包问题和流量控制。它是发送方的一个机制，记录了当前发送方的数据包发送情况，哪些发送了，哪些确认了，哪些需要重发等等。如图所示：

（1） 1-3 代表了服务端响应已经收到了，这时客户端就可以将其从缓存中去掉
（2） 4-9 代表了客户端已经发送了，但还没得到确认，至于服务端收没收到不确定
（3） 10-12 代表了还没发送却可以发送，因为当前网络是可以忙的过来的
（4） 13-15 代表了不仅没发送，这会还不能发送，要不然会让网络拥塞

接收端滑动窗口如下：

（1) 1-5代表我也经接收了，并且已经确认过的
（2) 6-14代表还没接收到，这是接收端还能接收到的最大数量了
（3) 15代表，不能接收的，接收了就处理不过来了
此时接收端的滑动窗口大小为：等待接收未确认的这部分，接收端会将这个值一同的返回给发送端，和发送端一起调节流量发送速度。
顺序问题和丢包问题
假设8和9接收端已经收到了。但是这时还不能接收，因为6/7还没有来，这就出现了顺序问题。假设4-7全部丢失了，那么接收端该怎么处理了，其实接收端会有个计时器，如果超过一定的时间（时间是根据网络情况自动的调节的），就默认丢了，就会重新的发送。
流量问题
流量是针对接收方来说的，如果接收方处理不过来，就会响应时一并发送窗口大小，如果窗口不断的变小，那么接收端也会调节大小。这样就会使接收方发送的数据减少。

2.7. TCP流量控制

2.7.1 什么是流量控制

接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被填满, 这个时候如果发送端继续发送, 就会造成丢包, 进而引起丢包重传等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度.
这个机制就叫做 流量控制(Flow Control)

2.7.2 流量控制流程

如上图，流程概述：

接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 “窗口大小” 字段,
通过ACK通知发送端;
窗口大小越大, 说明网络的吞吐量越高;
接收端一旦发现自己的缓冲区快满了, 就会将窗口大小设置成一个更小的值通知给发送端;
发送端接受到这个窗口大小的通知之后, 就会减慢自己的发送速度;
如果接收端缓冲区满了, 就会将窗口置为0;
这时发送方不再发送数据, 但是需要定期发送一个窗口探测数据段, 让接收端把窗口大小再告诉发送端.

那么接收端如何把窗口大小告诉发送端呢?

我们的TCP首部中, 有一个16位窗口大小字段, 就存放了窗口大小的信息;
16位数字最大表示65536, 那么TCP窗口最大就是65536字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是窗口字段的值左移 M 位(左移一位相当于乘以2).

2.8. TCP拥塞控制

拥塞控制, 归根结底是TCP协议想尽可能快的把数据传输给对方, 但是又要避免给网络造成太大压力的折中方案.

虽然TCP有了滑动窗口这个大杀器, 能够高效可靠地发送大量数据.
但是如果在刚开始就发送大量的数据, 仍然可能引发一些问题.
因为网络上有很多计算机, 可能当前的网络状态已经比较拥堵.
在不清楚当前网络状态的情况下, 贸然发送大量数据, 很有可能雪上加霜.
因此, TCP引入慢启动机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态以后, 再决定按照多大的速度传输数据.

2.8.1 拥塞窗口

发送开始的时候, 定义拥塞窗口大小为1;
每次收到一个ACK应答, 拥塞窗口加1;
每次发送数据包的时候, 将拥塞窗口和接收端主机反馈的窗口大小做比较, 取较小的值作为实际发送的窗口
当TCP开始启动的时候, 慢启动阈值等于窗口最大值
在每次超时重发的时候, 慢启动阈值会变成原来的一半, 同时拥塞窗口置回1
像上面这样的拥塞窗口增长速度, 是指数级别的.
“慢启动” 只是指初使时慢, 但是增长速度非常快.
为了不增长得那么快, 此处引入一个名词叫做慢启动的阈值, 当拥塞窗口的大小超过这个阈值的时候, 不再按照指数方式增长, 而是按照线性方式增长.
少量的丢包, 我们仅仅是触发超时重传;
大量的丢包, 我们就认为是网络拥塞;
当TCP通信开始后, 网络吞吐量会逐渐上升;
随着网络发生拥堵, 吞吐量会立刻下降.

3.UDP协议

3.1 TCP，UDP区别

对比项	TCP	UDP
是否面向连接	面向连接	面向非连接
传输可靠性	可靠	不可靠
应用场合	传输大量数据	少量数据
传输速度	慢	快

TCP提供面向连接的、可靠的字节流服务。面向连接意味着使用TCP协议作为传输层协议的两个应用之间在相互交换数据之前必须建立一个TCP连接。TCP通过确认、校验、重组等机制为上层应用提供可靠的传输服务。但是TCP连接的建立以及确认、校验等机制都需要耗费大量的工作并且会带来大量的开销。
UDP提供简单的、面向数据报的服务。UDP不保证可靠性，即不保证报文能够到达目的地。UDP适用于更关注传输效率的应用，如SNMP、Radius等，SNMP监控网络并断续发送告警等消息，如果每次发送少量信息都需要建立TCP连接，无疑会降低传输效率，所以诸如SNMP、Radius等更注重传输效率的应用程序都会选择UDP作为传输层协议。另外，UDP还适用于本身具备可靠性机制的应用层协议。

3.2 UDP协议简介

UDP协议特点：

UDP为应用程序提供面向无连接的服务。传输数据之前源端和目的端不需要建立连接。
不需要维持连接状态，收发状态等，因此服务器可同时向多个客户端传输相同的消息。
UDP适用于对传输效率要求高的运用。

UDP首部格式

UDP和TCP一样都使用IP作为网络层协议，TCP数据报被封装在一个IP数据包内。由于UDP不象TCP一样提供可靠的传输，因此UDP的报文格式相对而言较简单。

如上图UDP首部格式，下表对字段含义做一下简介：

字段	作用	说明
16位源端口号	为源端应用程序分配的一个源端口号
16位目的端口号	目的应用程序的端口号
16位UDP长度	是指UDP首部和UDP数据的字节长度。该字段的最小值为8
16位UDP检验和	该字段提供与TCP检验和同样的功能，只不过在UDP协议中该字段是可选的

4 IP协议

4.1 IP 包数据格式

IP packet 结构如下图：网络层收到传输层的TCP数据段后会再加上网络层IP头部信息。普通的IP头部固定长度为20个字节（不包含IP选项字段）。
IP报文头主要由以下字段组成：报文长度是指头部占32比特字的个数，包括任何选项。由于它是一个4比特字段，24=16，除掉全0项共有15个有效值比特字段，其中最大值也为15，表示头部占15个32比特。因此32*15/8=60字节，头部最长为60字节。

下面表对上图字段做一下介绍：

字段	作用	说明
版本号（Version）	字段标明了IP协议的版本号，目前的协议版本号为4。下一代IP协议的版本号为6。
8比特的服务类型（TOS，Type of Service）	字段包括一个3比特的优先权字段（COS，Class of Service），4比特TOS字段和1比特未用位。4比特TOS分别代表最小时延、最大吞吐量、最高可靠性和最小费用。
总长度（Total length）	是整个IP数据报长度，包括数据部分。由于该字段长16比特，所以IP数据报最长可达65535字节。尽管可以传送一个长达65535字节的IP数据报，但是大多数的链路层都会对它进行分片。而且，主机也要求不能接收超过576字节的数据报。UDP限制用户数据报长度为512字节，小于576字节。而事实上现在大多数的实现（特别是那些支持网络文件系统NFS的实现）允许超过8192字节的IP数据报。
标识符（Identification）	字段唯一地标识主机发送的每一份数据包。通常每发送一份报文它的值就会加1
生存时间（TTL，Time to Live）	字段设置了数据包可以经过的路由器数目。一旦经过一个路由器，TTL值就会减1，当该字段值为0时，数据包将被丢弃。
协议	协议字段确定在数据包内传送的上层协议，和端口号类似，IP协议用协议号区分上层协议。TCP协议的协议号为6，UDP协议的协议号为17。
报头校验和（Head checksum）	字段计算IP头部的校验和，检查报文头部的完整性。
源IP地址	字段标识数据包的源端设备
目的IP地址	字段标识数据包的目的端设备IP地址信息
IP选项

以太网帧格式 Ethernet frame

如上图以太网头部是由三个字段组成：DMAC , SMAC, L/T(LENGTH/TYPE字段)

以太网头部字段说明：

字段	作用	说明
DMAC	表示目的终端MAC地址。
SMAC	表示源端MAC地址
LENGTH/TYPE字段	根据值的不同有不同的含义：当LENGHT/TYPE > 1500时，代表该数据帧的类型（比如上层协议类型）常见的协议类型有：0X0800 IP数据包0X0806 ARP请求/应答报文0X8035 RARP请求/应答报文。当LENGTH/TYPE < 1500时，代表该数据帧的长度。

参考大神博客：https://www.jianshu.com/p/e4efd121a48c