运输层学习

• 运输层

作用 在IP层解决了两台主机通信的基础上，运输层解决了两个进程之间的通信。

怎么做 利用了端口来解决两个进程之间的通信问题，有一个端口来代表一个进程，发送方在运输层上加上彼此的端口号，而接收方在运输层把数据发到端口对应的程序那里，这也叫复用(共用传输层)和分用(传输层把数据交给不同程序)。

端口号

1. 服务端使用端口号（因为服务端需要监听这些端口，所以需要手动注册这些端口）
   A. 系统端口号：1-1023，已经成为默认。比如FTP21,SSH22,TELNET23,HTTP80,SSL443等。
   B. 登记端口号 : 1024-49151，比如Tomcat 8080
2. 客户端使用端口号 ： 49152-65535 ，客户端使用的端口号，由操作系统分配，短暂使用。

协议 运输层的协议有面向连接的传输控制XTCP协议 和 无连接的用户数据包UDP协议。

• UDP协议

作用 分用和复用，差错检测的功能。

首部 源端口 + 目标端口 + 长度 + 检验和

无连接 不用发连接请求给对方主机，即使对方主机不存在，他也能发送，这样子可以减少开销和发放时延。

尽最大努力交付 不保证可靠交付，如果途中有什么损失也不管。

面向报文 对应用层下来的报文直接加首部，不拆包也不合并，拆分合并等到IP层。

没有拥塞控制 就算网络出现拥塞现象，他也不会降低发放速率，这就是为什么播放视频会卡的原因。

通信方式 支持一对一，也支持一对多。

• TCP协议

• 作用

除了提供两个进程之间通信的功能以外，TCP协议还是一个面向连接，面向字节流，提供可靠传输，并且可以控制流量和控制拥塞的协议。

• 首部

TCP首部
源端口和目标端口 IP数据包有个协议字段来指定运输层用什么协议，TCP没有该字段，TCP根据目标端口的字段，把数据部分交给相应的目标程序，再由目标程序自己处理信息。

序号 TCP协议是面向字节流的，在一个TCP连接中，传送的数据部分(字节流)每个字节都有它的序号，序号就是第一个字节的编号。比如两个点已经建立了TCP连接，在某一次传输中序号为301，该次传输一共有100个字节，那么下一次传输的序号就是401。

确认号 期待下次收到TCP包的序号，还是上面的例子，该TCP包的确认号也为401。

数据偏移 TCP首部的长度。

紧急URG 当URG=1时，表示该TCP包是紧急包，应优先传送。比如我们按了Ctrl + C。

确认ACK 当ACK = 1时，表示确认号有效。当ACK = 0时，确认号无效。TCP规定，建立连接后的所有传送报文段都必须把ACK置为1。

同步SYN 建立连接时使用。如果SYN=1,ACK=0表示这是一个连接请求报文；如果SYN=1,ACK=1,表示这是一个连接确认报文。

终止FIN 释放连接时使用。当FIN=1时，表示这是一个连接终止报文，数据已经发放完毕，并要求关闭连接。

窗口 TCP的字节流是先放到一个缓存区的，窗口这个字段告诉接收方自己的缓存区还剩多大空间，接收方发过来的数据不要超过这个值。这样子可以控制接收方的发送速度。

选项 MSS:最大报文长度（TCP报文长度 - TCP首部长度）。为了减少传输过程中因为报文过大（超过MTU）而导致在IP层被分片问题，建立连接时会先确定一个MSS(两边报文取最小的MSS)，这个MSS一般等于MTU-IP首部 -TCP首部 = 1460B。以后在传输TCP报文，不要超过这个长度。

• 面向连接

定义 如果两个点之间要利用TCP协议传输数据，这两个点要先建立连接，如果不需要传输数据了，要手动把连接释放掉。

作用

1. 确认对方是否存在
2. 协商一些参数（比如最大窗口值，MSS等...）

建立连接(三次握手)

建立连接

1. 首先服务器B处于监听状态
2. 客户端A发送创建连接的请求，在该报文中SYN=1,ACK=0,SEQ=0,ACK number = 0，但是该数据包中不携带任何数据，因为规定SYN=1的数据包不能携带数据，发放成功后客户端处于同步已发放状态。
3. 服务端收到请求报文后，发送一个确认创建连接的报文，在该报文中，SYN=1,ACK=1,SEQ=0,ACK number = 1，然后处于同步已接收状态。
4. 客户端还要接着发送确认创建连接的报文，在该报文中，SYN=0, ACK=1,SEQ=1,ACK=1。发送完这个包以后，处于establish状态，双方就可以相互传数据了。

客户端为什么要多发送一次确认？
客户端给服务端发送了一次建立连接的请求，因为在一定时间内服务端没有回复给客户端，客户端以为请求丢失了，于是又发了一个建立连接的请求给服务端，这次服务端立刻收到了，将状态置于establish，并且回复了客户端。收到回复的客户端开始给服务端传送数据，传送完数据以后关闭连接。这时候第一个建立连接的请求历经艰险，终于来到了服务端，于是服务端又会处于establish状态了。这样子会造成不必要的资源浪费。

释放连接（四次挥手）

释放连接

1. 客户端发送释放连接的请求，在该请求中，FIN=1,ACK=1,seq=u，然后处于FIN-WAIT-1状态。
2. 服务端收到请求后，发送第一个确认释放连接的请求，在该请求中，ACK=1,FIN=0，ack =u + 1,然后处于close-wait状态。如果客户端收到请求会处于FIN-WAIT-2状态。在接下来一段时间内，客户端已经不能向服务端发送信息，而服务端会把还没发给客户端的数据发给客户端。
3. 当服务端把所有数据都发完以后，会再发一个确认释放连接的请求，ACK=1,FIN=1,ack=u+1,发完以后服务端处于last-ack状态。
4. 客户端收到服务端最后释放连接的请求后，会再发一个确认请求给服务端，ACK=1,FIN=0,收到请求的服务端会关闭与客户端的连接。而客户端在2msl（分钟）以后也会关闭连接。

客户端为什么要等2msl才关闭连接？
客户端发送最后的确认请求后，不确定服务端是否收到确认请求，并且关闭连接了，所以它就等啊等，如果服务端确实没有收到客户端最后的确认请求的话，客户端会再发一个确认最后释放连接的请求，客户端收到以后再发一个最后确认释放连接的请求，一直到关闭连接。

• 面向字节流

面向字节流

TCP把应用程序发下来的数据都当成是无结构的字节流，然后根据对方给出的窗口值和当前网络的拥塞情况，组成数据包发给对方，也就是说当应用程序发下来的数据过大时，tcp会把数据分为几个数据包并分别发送出去；当应用程序发下来的数据过小时，TCP可能也会等数据多起来以后再一起发出去。

• 可靠传输（连续ARQ协议）

所谓可靠，就是字节流在发送过程中不丢失，不重复，不差错，虽然停止发送协议也能做这样的事，但是效率低，而连续arq协议把一个个确认改成一组组确认，效率挺高了很多。

怎么做？

连续ARQ协议

1. 发送端缓存存储了发送和即将发送的字节流，TCP给每个字节都做了编号，我们分析TCP首部的时候提到的序号和确认号都是在说这个编号。
2. 发送的字节流都存储了三个指针，P1（后沿指针）后面表示已经发送并且确认的字节，P2后面和P1前面表示发送了但是还没确认的字节，P3后面和P2前面表示允许发送但是还没发送的字节，P3前面表示不允许发送的字节。P1前面和P3后面就是我们所说的发送窗口。发送窗口的大小是根据接收端发过来的窗口字段及网络情况综合决定的。
3. 同理，在接收端也维持着一个接收窗口。
4. 假如现在有发送端和接收端刚建立好TCP连接，发送端根据接收端的窗口值（假如是100）在发送端缓存中建立好了发送窗口，假如现在从应用层下来了30个字节的数据，那么在发送端的编号就是1-30， 此刻P1指的就是1，P2指的就是31，P3指的就是101。TCP把这三十个字节封装成包发送出去。
   A. 如果发出去的字节的包在半路丢失了，发送端在一定的时间内如果收不到接收端的确认就会把刚刚的包再发送一次。
   B. 如果发送端因为以为接收端数据丢失，然后再发送了一个包，实际上只是因为网络延迟，比较晚接收到这个包而已，当第二个包来时，因为该包的所有字节流都已经占了位，所以这个包的数据都会被丢弃。
   C. 如果发送出去的包是1-30，但是实际上接收端只接收了2-30，也就是说1在半路上丢失了，这时接收端回复的确认号还是1，也就是说接收端下次发送还是得从1开始发送起。
   D. 接收端接收到重新发过来的字节流，会把原来的缺的1和不缺的2-30都覆盖掉，再检查是否完整，然后确认。
   E. 假设接收端千辛万苦终于把确认包给发送出去了，确认号为31，发送端也成功接收到了确认包，它会把P1指针移到P2位置，根据Windows大小确认P3的位置，如果有新的数据下来，还会移动P2的位置。

• 半包和粘包问题

短连接
创建连接->传输数据->关闭连接
也就是说短连接就是传输完数据马上关闭连接的socket，比如http连接。

长连接
创建连接->传输数据->保持连接->传输数据->关闭连接
长连接就是传输完数据不会马上关闭连接，并且可以持续传输数据的socket，比如QQ聊天。

粘包

1. 引起原因
   A. 发送端相等缓存区满了以后再一起发送
   B. 接收端不能及时处理缓存区的数据，当新的数据进来会造成粘包
2. 什么时候需要考虑粘包问题
   A. 长连接需要考虑
   B. 数据包的数据结构不一致
3. 解决方法
   A. 对于发送端造成的粘包问题，可以利用push字段来解决，比如应用程序发给TCP层数据后，立即给一个push指令，就会把刚刚的数据全部发送出去，而不必等到数据堆满,但是这样子取消了TCP的优化发送设置，明显降低了发送速率。
   B. 对于接收方引起的粘包，则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施，使其及时接收数据，从而尽量避免出现粘包现象，这个只能降低粘包的可能
   C. 由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包，这样子会影响接收速率
   a. 给数据包加上长度字段
   b. 每个数据包结尾加上特殊符号以表示结束
   c. 给数据包规定长度大小，不满足的充填

半包

1. 引起原因
   发送端发送的数据包过大，在发送或者接收过程中被分成多个包。
2. 解决方法
   把数据包结构化，比如上面的a，b，c

• 流量控制

定义 流量控制是接收方为了防止发送方发送过快而导致自己无法及时接收出现数据丢失采取的控制发送方发送速率的一种策略，它是通过控制窗口字段来实现的。