应用层 ：负责应用程序间沟通，如简单电子邮件传输（ SMTP ）、文件传输协议（ FTP ）、网络远程访问协议（ Telnet ）等。我们的网络编程主要就是针对应用层。
传输层 ：负责两台主机之间的数据传输。如传输控制协议 (TCP) ，能够确保数据可靠的从源主机发送到目标主机。
网络层 ：负责地址管理和路由选择。例如在 IP 协议中，通过 IP 地址来标识一台主机，并通过路由表的方式规划出两台主机之间的数据传输的线路（路由）。路由器（ Router ）工作在网络层。
数据链路层 ：负责设备之间的数据帧的传送和识别。例如网卡设备的驱动、帧同步 ( 就是说从网线上检测到什么信号算作新帧的开始 ) 、冲突检测 ( 如果检测到冲突就自动重发 ) 、数据差错校验等工作。有以太网、令牌环网，无线 LAN 等标准。交换机（ Switch ）工作在数据链路层。
物理层 ：负责光 / 电信号的传递方式。比如现在以太网通用的网线 ( 双绞线 ) 、早期以太网采用的的同轴电缆 ( 现在主要用于有线电视 ) 、光纤，现在的 wifi 无线网使用电磁波等都属于物理层的概念。物理层的能力决定了最大传输速率、传输距离、抗干扰性等。集线器（ Hub ）工作在物理层。

TCP/IP协议每一层中的核心内容如下。

1.应用层协议

在开发应用程序时，一个大的工作就是进行协议的确定。如果三个程序相互通信，那么就要实现对方协议的编解码工作，于是，大佬就对常用的应用场景做了一些特殊协议并确定下来，形成了标准常见的应用层协议。

协议：约定数据的组织格式

常见的数据组织格式（协议）：

①XML

②JSON

③其他协议

2.传输层协议

传输层协议负责数据能够从发送端传输到接收端。

核心的协议有两个：

①UDP，无连接，不可靠传输，面相数据报，全双工，大小受限

②TCP，有连接，可靠传输，面相字节流，全双工，大小不限

2.1UDP协议

UDP协议格式

16位UDP长度（65535byte约等于64kb），表示整个数据报（UDP首部+UDP数据）的最大长度
16位UDP校验和，通过对数据（byte数组）中每个byte累加，得到的值
如果校验和出错，就会直接丢弃

UDP是传输层协议，操作系统负责实现的，用于确定程序的端口号。

上图这样表示是因为排版原因，其实协议的组成是按顺序排列的：

16位源端口号

16位目的端口号

16位UDP长度

16位校验和

数据长度

在解析数据文件时，先解析16位表示源端口，再解析16位表示目的端口，以此类推。

UDP协议特点

UDP 传输的过程类似于寄信。

无连接

知道对端的 IP 和端口号就直接进行传输，不需要建立连接；

不可靠

没有任何安全机制，发送端发送数据报以后，如果因为网络故障该段无法发到对方， UDP 协议层也不会给应用层返回任何错误信息；

面向数据报

应用层交给 UDP 多长的报文， UDP 原样发送，既不会拆分，也不会合并；

用 UDP 传输 100 个字节的数据：

如果发送端一次发送 100 个字节，那么接收端也必须一次接收 100 个字节；而不能循环接收 10 次，每次接收 10 个字节。

缓冲区

UDP 只有接收缓冲区，没有发送缓冲区：

UDP 没有真正意义上的 发送缓冲区 。发送的数据会直接交给内核，由内核将数据传给网络层协议进行后续的传输动作；

UDP 具有接收缓冲区，但是这个接收缓冲区不能保证收到的 UDP 报的顺序和发送 UDP 报的顺序一致；如果缓冲区满了，再到达的 UDP 数据就会被丢弃；

UDP 的 socket 既能读，也能写，这个概念叫做 全双工

大小受限

UDP 协议首部中有一个 16 位的最大长度。也就是说一个 UDP 能传输的数据最大长度是 64K （包含 UDP 首部）。

2.2TCP协议

TCP ，即 Transmission Control Protocol ，传输控制协议。人如其名，要对数据的传输进行一个详细的控制。

TCP协议格式

源/目的端口号：表示数据是从哪个进程来，到哪个进程去；
32位序号/32位确认号：下文详细讲；
4位TCP报头长度：表示该TCP头部有多少个32位bit（有多少个4字节）；所以TCP头部最大长度是 15 * 4 = 60 （1111=15*4byte=60byte）
6位标志位:

URG：紧急指针是否有效

ACK：确认号是否有效

PSH：提示接收端应用程序立刻从TCP缓冲区把数据读走

RST：对方要求重新建立连接；我们把携带RST标识的称为复位报文段

SYN：请求建立连接；我们把携带SYN标识的称为同步报文段

FIN：通知对方，本端要关闭了，我们称携带FIN标识的为结束报文段

16位窗口大小：后面再说
16位校验和：发送端填充，CRC校验。接收端校验不通过，则认为数据有问题。此处的检验和不光包含TCP首部，也包含TCP数据部分。
16位紧急指针：标识哪部分数据是紧急数据；
40字节头部选项：暂时忽略；

TCP的安全和效率机制（TCP原理）

TCP 对数据传输提供的管控机制，主要体现在两个方面：安全和效率。

这些机制和多线程的设计原则类似：保证数据传输安全的前提下，尽可能的提高传输效率。

①确认应答（可靠机制）

一发一收的过程就是确认应答。

举例说明：

由于网络的原因肯出现收发乱序的问题（例如，先收到“滚”消息再受到“好”）

TCP为了解决收发乱序的问题，对每个字节编号，即为序列号。

每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始法。

继续刚才的例子：

ACK应答，已经收到7个字节，下次从第8个字节开始发。

②超时重传（可靠机制）

消息在网络中的传输过程中，经过的设备:

操作系统－>网卡－>交换机－>路由器－>其他网络设备

每个设备都有自己的负载能力，如果超出了范围，当前数据包就可以阻塞或丢弃。

超时重传一般有两种情况：

情况1：发送方丢包，由于网络原因，造成数据没有发送成功

情况2：响应超时，主机B接收到了数据，并发出ACK的应答，主机A只是没有接收到应答，即ACK丢包

这种情况下会有一个重复接收（重新发送ACK，直到接收）的问题，那么TCP协议需要能够识别出哪些包是重复的包，并且把重复的丢弃掉。

我们可以利用前面提到的序列号，就很容易做到去重效果。

那么，如果超时的时间如何确定？

最理想的情况下，找到一个最小的时间，保证 " 确认应答一定能在这个时间内返回 " 。

但是这个时间的长短，随着网络环境的不同，是有差异的。

如果超时时间设的太长，会影响整体的重传效率；

如果超时时间设的太短，有可能会频繁发送重复的包；

TCP 为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

Linux 中（ BSD Unix 和 Windows 也是如此），超时以 500ms 为一个单位进行控制，每次判定

超时重发的超时时间都是 500ms 的整数倍。

如果重发一次之后，仍然得不到应答，等待 2*500ms 后再进行重传。如果仍然得不到应答，等待 4*500ms 进行重传。依次类推，以指数形式递增。

累计到一定的重传次数， TCP 认为网络或者对端主机出现异常，强制关闭连接。

③连接管理（可靠机制）

主机之间作为发送方和接收方在网络通信，必须要确认双方收发数据的能力，其中涉及到建立连接与断开连接的协商过程。

正常情况下，TCP要经过三次握手建立连接，四次挥手断开连接。

1.正常通信之前确认双方能力，✨三次握手的过程。

通过两次SYN和ACK的过程就可以保证双方网络都没有问题。在这个基础上就可以保证收发数据的正常进行。

三次握手是把SYN和ACK合并成一次通信完成，从而提高效率

三次握手还有一个重要功能就是协商序列号是从哪开始的。发送方随机生成一个序列号，ACK对序列号进行加1操作，接收方随机生成一个序列号，ACK再对序列号进行加1操作

2.✨四次挥手（断开的过程）

FIN 客户端发送的断开请求，被服务器接收并应答，服务器就会做一些断开前的准备。

ACK是操作系统实现的TCP协议的应答，第二个FIN，是应用程序级别的，这两个操作之间是有时间差的，大概率不会合并到一起返回，所以定义为四次挥手。

④滑动窗口（效率机制）

刚才我们讨论了确认应答策略，对每一个发送的数据段，都要给一个 ACK 确认应答。收到 ACK 后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差。尤其是数据往返的时间较长的时候。

数据能过，一收一发的过程，可以保证正常通信，但是效率不高。

既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能（其实是将多个段的等待时间重叠在一起了）。

窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是4000 个字节（四个段）。
发送前四个段的时候，不需要等待任何ACK，直接发送；
收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据；依次类推；
操作系统内核为了维护这个滑动窗口，需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答；只有确认应答过的数据，才能从缓冲区删掉；
窗口越大，则网络的吞吐率就越高；

滑动窗口本身是一种数据结构，维护窗口的大小，以及已经发送和正在发送的数据块。

可以预见的丢包问题：

情况1：数据包已经抵达，ACK被丢了

这种情况下，部分ACK丢了并不要紧，因为可以通过后序的ACK进行确认。

这就像是，别人问你是什么学历，你说大学本科，这就意味着，小学，初中，高中已经上过了。

情况2：发送方的请求包（数据包）丢了

当某一段报文段丢失之后，发送端会一直收到 1001 这样的ACK，就像是在提醒发送端 "我想要的是 1001" 一样；
如果发送端主机连续三次收到了同样一个 "1001" 这样的应答，就会将对应的数据 1001 - 2000 重新发送；
这个时候接收端收到了 1001 之后，再次返回的ACK就是7001了（因为2001 - 7000）接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中；

这种机制被称为“高速重发控制”（也叫“快重传”）

滑动窗口与效率：

效率的高低取决于窗口的大小
窗口越大效率越高
窗口越小效率越低
假设窗口无穷大，此时发送方就完全不需要等待ACK，此时效率就和UDP一样

⑤流量控制（可靠机制）

接收端处理数据的速度是有限的。如果发送端发的太快，导致接收端的缓冲区被打满，这个时候如果发送端继续发送，就会造成丢包，继而引起丢包重传等等一系列连锁反应。

因此 TCP 支持根据接收端的处理能力，来决定发送端的发送速度。这个机制就叫做 流量控制。

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

1.发送与接收缓冲区

每个程序在启动时都会去申请系统资源，发送与接收缓冲区就是申请来的资源。

通过接收方反制发送方对于窗口大小的限制，发送方不能为了提高效率而无限制的扩大窗口大小。

已使用空间与剩余空间都的大小是动态变化的，每次接收方从缓冲区读取数据之后，剩余空间就会变大。

如果接收方的处理能力比较低，可能会出现缓冲区装满的情况。

解决窗口大小问题

⑥拥塞控制（可靠机制）

虽然 TCP 有了滑动窗口这个大杀器，能够高效可靠的发送大量的数据。但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。

因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下，贸然发送大量的数据，是很有可能引起雪上加霜的。

TCP 引入 慢启动 机制，先发少量的数据，探探路，摸清当前的网络拥堵状态，再决定按照多大的速度传输数据；

在每次的通信过程中试探网络的拥堵状态，从而调整窗口的大小。

此处引入一个概念程为拥塞窗口
发送开始的时候，定义拥塞窗口大小为1；
每次收到一个ACK应答，拥塞窗口加1；
每次发送数据包的时候，将拥塞窗口和接收端主机反馈的窗口大小做比较，取较小的值作为实际发送的窗口；

像上面这样的拥塞窗口增长速度，是指数级别的。 " 慢启动 " 只是指初使时慢，但是增长速度非常快。

为了不增长的那么快，因此不能使拥塞窗口单纯的加倍。
此处引入一个叫做慢启动的阈值
当拥塞窗口超过这个阈值的时候，不再按照指数方式增长，而是按照线性方式增长

当TCP开始启动的时候，慢启动阈值等于窗口最大值；
在每次超时重发的时候，慢启动阈值会变成原来的一半，同时拥塞窗口置回1；

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；

当 TCP 通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；拥塞控制，归根结底是 TCP 协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的

折中方案。

⑦延迟应答（效率机制）

如果接收数据的主机立刻返回 ACK 应答，这时候返回的窗口可能比较小。

假设接收端缓冲区为 1M 。一次收到了 500K 的数据；如果立刻应答，返回的窗口就是 500K ；

但实际上可能处理端处理的速度很快， 10ms 之内就把 500K 数据从缓冲区消费掉了；

在这种情况下，接收端处理还远没有达到自己的极限，即使窗口再放大一些，也能处理过

来；

如果接收端稍微等一会再应答，比如等待 200ms 再应答，那么这个时候返回的窗口大小就是

1M ；

一定要记得，窗口越大，网络吞吐量就越大，传输效率就越高。我们的目标是在保证网络不拥塞的情况下尽量提高传输效率；

那么所有的包都可以延迟应答么？肯定也不是；

数量限制：每隔N个包就应答一次；
时间限制：超过最大延迟时间就应答一次；

具体的数量和超时时间，依操作系统不同也有差异；一般 N 取 2 ，超时时间取 200ms ；

⑧捎带应答（效率机制）

由于延迟应答的存在，可能存在SYN报文和ACK报文同时发送的情况，那么系统就会把两个报文合二为一。

⑨面向字节流

类似于这种不能有效区分消息边界的现象叫做“粘包问题”。

解决粘包问题：

1.在消息的末尾加上特殊的分隔符来标识消息结束

2.使用一个专门用来描述消息体长度的字段，来标识消息体的长度

当读取消息之前，先把4byte的表示消息体长度的字段内容读出来，值=42
继续在缓冲区里读42个字节，这42个字节就可以表示消息的内容
再读4byte表示下一个消息的长度，反复执行即可

JSON，用大括号包裹消息体，，那么就可以理解为它是使用大括号作为特殊字符来表示消息结尾的

HTTP，应用层的协议，即使用了分隔符也使用了表示消息长度的字段解决粘包问题

⑩TCP异常情况

1.程序崩溃

操作系统会回收进程的资源，其中释放包括文件描述符表，就相当于调用了对应socket的close，之后出发FIN操作，进而开始进行四次挥手，和普通的四次挥手没有区别。

2.正常关机

通过开始菜单或执行关机命令，系统会强制结束所有进程，回收资源，与系统崩溃流程类似

3.主机掉电

①接收方掉电

发送方并不知道接收方挂了，继续发送数据
发送数据后收不到ACK应答，触发超时重发
多次重传都没有收到ACK应答，会尝试进行连接重置（RST标志位）
连接重置也失败，只能放弃连接

②发送方掉电

一般出现在长连接中，服务端与客户端会维护一个心跳包（告诉对方我还在线，没有真实数据，客户端每隔一秒给服务端发送一个数据报，证明自己存活）
如果服务器一直收不到心跳包，比如过了10秒之后，还没有收到，就判断为客户端不在了，自行断开连接
客户端网络恢复之后再次进行重连即可

4.网络断开

与主机掉电情况相同，只不过主机是正常工作的

3.网络层协议

3.1IP协议

协议格式:

4位版本号（version）:指定IP协议的版本，对于IPv4来说，就是4。
4位头部长度（header length）：IP头部的长度是多少个32bit，也就是 length * 4 的字节数。4bit表示最大的数字是15，因此IP头部最大长度是60字节。
8位服务类型（Type Of Service）：3位优先权字段（已经弃用），4位TOS字段，和1位保留字段（必须置为0）。4位TOS分别表示：最小延时，最大吞吐量，最高可靠性，最小成本。这四者相互冲突，只能选择一个。对于ssh/telnet这样的应用程序，最小延时比较重要；对于 ftp这样的程序，最大吞吐量比较重要。
16位总长度（total length）：IP数据报整体占多少个字节。
16位标识（id）：唯一的标识主机发送的报文。如果IP报文在数据链路层被分片了，那么每一个片里面的这个id都是相同的。
3位标志字段：第一位保留（保留的意思是现在不用，但是还没想好说不定以后要用到）。第二位置为1表示禁止分片，这时候如果报文长度超过MTU，IP模块就会丢弃报文。第三位表示"更多分片"，如果分片了的话，最后一个分片置为0，其他是1。类似于一个结束标记。
13位分片偏移（framegament offset）：是分片相对于原始IP报文开始处的偏移。其实就是在表示当前分片在原报文中处在哪个位置。实际偏移的字节数是这个值 * 8 得到的。因此，除了最后一个报文之外，其他报文的长度必须是8的整数倍（否则报文就不连续了）。
8位生存时间（Time To Live，TTL）：数据报到达目的地的最大报文跳数。一般是64。每次经过一个路由，TTL -= 1，一直减到0还没到达，那么就丢弃了。这个字段主要是用来防止出现路由循环。
8位协议：表示传输层使用的什么协议。
16位头部校验和：使用CRC进行校验，来鉴别头部是否损坏。
32位源IP地址和32位目标IP地址：表示发送端和接收端。
选项字段（不定长，最多40字节）：略。
数据：载荷，传输层发来的数据