网络原理之TCP_IP

应用层重点协议

传输层重点协议

1.UDP协议

(一)UDP协议段格式

我们知道TCP/IP五层（或四层）模型包括：

应用层

传输层

网络层

数据链路层

物理层

那网络传输是怎样具体展开的呢~

举个例子（发送方"封装"）（接收方要"分用"）

下面我们就来学习各个层的重点协议~~

应用层重点协议

传输层重点协议

1.UDP协议

(一)UDP协议段格式

16位UDP长度，表示整个数据报(UDP首部+UDP数据)的最大长度

如果校验和出错，就会直接丢弃

(二)UDP的特点

无连接

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

不可靠传输

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

面向数据报

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

全双工

UDP的socket既能读也能写

缓冲区

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

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

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

大小受限

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

(三)基于UDP的应用层协议

NFS：网络文件系统
TFTP：简单文件传输协议
DHCP：动态主机配置协议
BOOTP：启动协议（用于无盘设备启动）
DNS：域名解析协议

当然，也包括你自己写UDP程序时自定义的应用层协议。

(四)面试题

UDP本身是无连接，不可靠，面向数据报的协议，如果要基于传输层UDP协议，来实现一个可靠传输，应该如何设计？
UDP大小是受限的，如果要基于传输层UDP协议，传输超过64K的数据，应该如何设计？

以上两个问题答案类似，都可以参考TCP的可靠性机制在应用层实现类似的逻辑：

例如：

引入序列号，保证数据顺序；

引入确认应答，确保对端收到了数据；

引入超时重传，如果隔一段时间没有应答，就重发数据；

......

2.TCP协议

(一)TCP协议段格式

(二)TCP的特点

有连接

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

那啥叫断开连接呢？

A和B把自己存储的连接信息(数据结构)删了，连接就是断开了~~

三次握手：

建立连接阶段，主要认识两个状态：

1.LISTEN 服务器的状态

表示服务器已经准备就绪，随时可以跟客户端来建立连接，相当于手机开机，信号良好，随时可以有人来打电话~~

2.ESTABLISHED 客户端和服务器都有

表示连接建立完成，接下来就可以正常通信了，相当于电话拨过去，对方接通了~~

四次挥手：

断开连接阶段，主要认识两个状态：

1.TIME_WAIT

TIME_WAIT表示要保持当前的TCP连接状态不要立即就释放~

为什么不要连接释放呢？

TIME_WAIT如果等待了一段时间后也没收到重传的FIN，此时就认为，最后的一个ACK没丢，于是就彻底的释放连接了~

2.CLOSE_WAIT 出现在被动发起断开连接的一方

建立连接一定是客户端主动发起请求的，断开连接，可能是客户端主动发起，也可能是服务器主动发起~

CLOSE_WAIT表示等待关闭，等待调用close方法关闭socket
有连接和确认应答的区别：

可靠传输

确认应答机制

网络后发先至这个现象是客观存在的，如何解决这个问题呢？

方法很简单，给传输的数据和应答报文，都进行编号就可以了！！！

TCP将每个字节的数据都进行了编号。即为序列号。

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

超时重传机制

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

如果一直丢包，主机A会一直重传吗？

答案是不会的~

但是，主机A未收到B发来的确认应答，也可能是因为ACK丢失了；

由于主机B返回的确认应答因网络堵塞等原因在传输的途中丢失，没有到达主机A，主机A会等待一段时间，若在特定时间间隔始终未能收到确认应答，主机A会对此数据进行重发，此时，主机B将第二次发送已接收数据的确认应答，由于主机B已经收到过1~1000的数据，当再有重复数据送达时它会放弃~~

滑动窗口机制

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

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

当批量发送了窗口大小的这些数据之后，发送方就要等待ACK了

那么啥时候继续往下发送呢？发送方不是等待所有的ack到达才继续往下发，而是到了一个ack，就继续往下发一条...

如上图的例子，那么我们等待的ack始终是4条~

那么如果出现了丢包，如何进行重传？这里分两种情况讨论。

情况一、数据包丢了

情况二、ack丢了

流量控制机制

这是一种干预发送窗口大小的机制

滑动窗口越大，传输效率越高（一份时间，等待的ack越多）

但是，窗口也不能无限的大~否则会造成以下的问题：

1.完全不等ack，可靠性能否保障画上问号

2.窗口越大，也会消耗大量的系统资源

3.发送速度太快，接收方处理不过来，发了也白发

接收方的处理能力，就是一个很重要的约束依据

发送方发数据的速度，不能超过接收方的处理能力

流量控制要做的工作就是这个，根据接收方的处理能力，协调发送方的发送效率

那如何衡量接收方的处理能力？

其实可以直接看接收方接收缓冲区的剩余大小~

当窗口大小为0，发送方就要暂停发送，暂停发送的等待过程中，会给B定期发送窗口探测报文，这个报文不携带具体的业务数据，只是为了触发ack查询窗口大小~~

延时应答机制

面向字节流

缓冲区

创建一个TCP的socket，同时在内核中创建一个发送缓冲区和一个接收缓冲区；

前面我们说过~网络上的传输可能后发先至

TCP使用这个接收缓冲区，对接收的数据进行重新排序，使应用程序read到的数据是保证有序的（和发送顺序一致）

全双工

既可以读数据，也可以写数据。

粘包问题

首先要明确，粘包问题中的 "包" ，是指的应用层的数据包。

在TCP的协议头中，没有如同UDP一样的 "报文长度" 这样的字段，但是有一个序号这样的字段。

站在传输层的角度，TCP是一个一个报文过来的。按照序号排好序放在缓冲区中。

站在应用层的角度，看到的只是一串连续的字节数据。

那么应用程序看到了这么一连串的字节数据，就不知道从哪个部分开始到哪个部分，是一个完整的应用层数据包。

那么如何避免粘包问题呢？

归根结底就是一句话，明确两个包之间的边界。

对于定长的包，保证每次都按固定大小读取即可；

就从缓冲区从头开始按sizeof（）依次读取即可；

对于变长的包，可以在包头的位置，约定一个包总长度的字段，从而就知道了包的结束位置；

对于变长的包，还可以在包和包之间使用明确的分隔符（应用层协议，是程序猿自己来定的，只要保证分隔符不和正文冲突即可）；

异常情况

(三)基于TCP应用层协议

HTTP
HTTPS
SSH
Telnet
FTP
SMTP
当然，也包括你自己写TCP程序时自定义的应用层协议；

网络层重点协议

IP协议

协议头格式如下：

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都是相同的。

**16位头部校验和：**使用CRC进行校验，来鉴别头部是否损坏。

32位源地址和32位目标地址：表示发送端和接收端。

举个例子：

我们来想一个问题~如果IP地址不够用了怎么办？

1.动态分配IP地址。此时就可以省下一大批IP地址了，但是这个方案没有从根本上增加IP地址，只是提高了利用率，治标不治本~

2.NAT网络地址转换，本质是使用一个IP地址代表一批设备，使用端口号区分，能够大大提高IP地址的利用率

3.IPv6 (从根本解决IP不够用的问题)

使用16字节，表示IP地址，