网络基础传输层

一、传输层功能：负责端与端之间的数据传输

二、端口：用来标识一个进程，一个端口只能被一个进程占用，而一个进程可以占用多个端口。

 1. 0~1023：知名端口号，是留着备用的，一把都是用于协议，例如HTTP、FTP、SSH。
 2. 1024~65535：是操作系统动态分配的端口号，客户端程序的端口号，就是由操作糸统从这个范围来分配的，在TCP与UDP的套接字通信中，客户端的端口号就是在此范围中。

 3. 部分知名端口号：

FTP服务器：21号；

SSH服务器：22号；

SMTP服务器：25号；

HTTP服务器：80号；

HTTPS服务器：443号；

4. 查看网络状态命令：netstate

-n：不显示地址别名

-a：全部显示

-p：显示建立相关链接的程序名

-t：仅显示与tcp有关信息

-u：仅显示与udp有关信息

-l：仅显示监听状态的服务信息

三、UDP协议 

 1. UDP协议段格式                            

                                  

     16位UDP长度：表示整个数据报（UDP首部+UDP数据）的最大长度。

     16位校验和：一条数据发送到传输层封装了UDP协议报头后直接进行发送，对端接收到UDP报文后，对整个UDP报文进行二进制反码求和，判断收到的报文是否和发送的一样。

 2. UDP协议特点

      （1）无连接：不需要建立连接，只需要知道地址信息就可以直接发送数据。

      （2）不可靠：没有确认机制、重传机制，所以并不关注数据是否到达，如果没有发送到，也不会返回错误信息。

      （3）面向数据报：不能够灵活地控制读写数据的次数和数量，如果要发送很大字节的数据，则需要用户在应用层对这个数据进行分段，因为UDP不会再传输层自动分段，数据只能一整条一整条交付给应用层，所以传输不够灵活；但是由于UDP的协议端中具有16位的UDP长度，所以可以知道数据的大小，不会产生数据粘包问题。

 3. 基于udp的应用层协议

• DHCP（动态主机配置协议）
• DNS（域名解析协议）
• NFS（网络文件系统）

 4. UDP的缓冲区

• udp没有真正意义上的发送缓冲区，调用sendto会直接交给内核，由内核将数据传给网络层协议后进行后续的传输动作。
• udp具有接收缓冲区，但是接收缓冲区不能保证收到的udp报文的顺序和发送的udp报文顺序一样；如果缓冲区满了，在到达的udp数据就会被丢弃。

四、TCP协议

  1.TCP协议段格式

• 源/目的端口：标识数据从哪个进程来，到哪个进程去。
• 32位序号/32位确认号：
• 4位TCP报文首部长度：表示该TCP报文头部有多少个32位bit了所以TCP头部最大长度位15 * 4 = 60 字节。
• 6位保留：这些位必须是0。为了将来定义新的用途所保留。
• 6位标志位

URG：紧急指针是否有效

ACK：确认号是否有效；取值1代表Acknowledgment Number字段有效，这是一个确认的TCP包，取值0则不是确认包。

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

RST：对方要求重新建立连接，通常在发生异常或者错误的时候会触发复位TCP连接；我们把携带RST标识的称为复位报文段

SYN：请求建立连接，该标志仅在三次握手建立TCP连接时有效；我们把携带SYN标识的称为同步报文段

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

• 16位窗口大小：该值指示了从Ack Number开始还愿意接收多少byte的数据量，也即用来表示当前接收端的接收窗还有多少剩余空间，用于TCP的流量控制。
• 16位校验和：发送端填充CRC校验，接收端校验不通过，则认为数据有问题。 此处的检验和不光包含TCP首部，也包含TCP数据部分。
• 16位紧急指针: 标识哪部分数据是紧急数据，在URG标志设置了时才有效，如果URG标志没有被设置，紧急域作为填充。

2. TCP协议特点

• 面向连接：需要通过三次握手建立连接。
• 传输可靠：有连接管理机制、确认应答机制、超时重传机制、确认序号校验和等复杂操作使得其传输可靠。
• 面向字节流：对数据按照以字节为单位的流式传输，使得传输比较灵活但是会有粘包问题。

3. 三次握手和四次挥手

https://blog.csdn.net/qq_43581695/article/details/97522533

    TIME_WAIT状态：如果没有TIME_WAIT状态，客户端直接关闭，但是又重启了相同的地址的客户端，有可能因为四次挥手最后一次ACK丢失，导致服务器重传FIN包，新客户端发送SYN到服务端建立新的连接，这样这个重传的FIN包就对其造成了影响，服务端认为状态有误，回复重新连接RST报文。因此主动关闭方发送最后一个ACK后不能直接关闭，需要等待2个MSL（报文最大生命周期）。这是为了能够处理对端重传的FIN包进行ACK回复，并且为了让所有网络中延迟的报文都消失在网络中，不会对后续链接造成影响。

4.确认应答机制

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

5. 超时重传机制

• 主机A发送数据给主机B之后，可能因为网络拥堵等原因，数据无法到达主机B，如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。
• 如果主机B接收到了数据，但是主机A没有收到主机B发送的确认应答，也可能是因为ACK丢失了。这样主机B会收到很多重复数据。那么TCP协议需要能够识别出那些包是重复的包，并且把重复的丢弃掉。这时候我们可以利用前面提到的序列号， 就可以很容易做到去重的效果。
• TCP为了保证无论在任何环境下都能比较高性能的通信，因此会动态计算这个最大超时时间。

6. 滑动窗口机制

• 对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段。这样做有一个比较大的缺点，就是性能较差，尤其是数据往返的时间较长的时候。既然这样一发一收的方式性能较低，那么我们一次发送多条数据，就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
• 窗口大小指的是无需等待确认应答二可以继续发送数据的最大值，窗口却大，则网络的吞吐率越高。收到第一个ACK后，滑动窗口向后移动，继续发送后面的数据，依此类推。
• 如果数据包都接收到了，而部分ACK被丢了，可以通过后续的ACK确认，所并没有太大问题。
• 如果数据包直接丢失，接收端回想发送端发送三次重传请求，若发送端连续接收到三条重传请求，则对该数据进行重传。

7. 流量控制

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

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

接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中，有一个16位窗口字段，就是存放了窗口大小信息；那么问题来了，16位数字最大表示65535，那么TCP窗口最大就是65535字节么? 实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移 M 位。

8. 拥塞窗口机制

通信初始双方通过协商窗口大小，窗口可能很大，一次性会发送很多数据，可能会因为网络原因导致大量丢包，导致重传。发送端维护一个拥塞窗口，控制/限制发送端发送的数据大小，这个数字随每次ACK回复的确认回复快速增长，但是一旦出现丢包，则立即重新初始化。

少量的丢包，我们仅仅是触发超时重传；大量的丢包，我们就认为网络拥塞；当TCP通信开始后，网络吞吐量会逐渐上升；随着网络发生拥堵，吞吐量会立刻下降；拥塞控制，归根结底是TCP协议想尽可能快的把数据传输给对方，但是又要避免给网络造成太大压力的折中方案。

9. 延迟应答机制

因为接受双方有可能很快就会把数据从缓冲区拿走，这样返回的窗口可能会很小，假设接收端缓冲区为1M，一次收到了500K的数据，返回的窗口就是500K；但是世家可能处理段处理的速度很快，这种情况下，接收端处理远没有达到自己的极限，即使窗口再放大一些，也可能处理过来；所以如果再稍微等一下再应答，那么这个时候返回的窗口可能就是1M了。

但是不是所有的包都有延迟应答。在数量上会每隔N个包就应答一次；在时间上，超过最大延迟时间就应答一次。

10. 捎带应答机制

尽可能避免纯报头的确认回复。在延迟应答的基础上，很多情况下，客户端服务器在应用层是一发一收。这是ACK也可以搭顺风车，将确定应答直接标记在即将发送的数据报内，那么这样不仅传输了数据还对上一次接收到的数据处进行应答（少传输一个应答）。

11.TCP的粘包问题

产生原因：内核没有对要发送的数据进行明确的边界区分，即可能在发射端产生，也可能是由于接收端来不及处理上一条数据而                    产生。

解决办法：在应用层给数据增加边界：特殊字符间隔；数据定长；在不定长数据的应用协议中定义数据长度等。

12. TCP异常

• 进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
• 机器重启: 和进程终止的情况相同.
• 机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即
• 使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
• 另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ 断线之后, 也会定期尝试重新连接.

​​​​​​​13. UDP如何实现可靠传输

      引入TCP可靠传输中的各种机制即可。

14. 基于TCP的应用层协议

• HTTP
• HTTPS
• SSH
• Telnet
• FTP
• SMTP