首先应该明确一个思路：
在TCP/IP协议中，用 源IP，源端口号，目的IP，目的端口号，协议号 这样一个五元组来标识一个网络通信（通过netstat -n查看）
那么传输层如何把有效载荷交给应用层？
1.将报头和有效载荷分离；
2.有效载荷通过某种方式交到上层（报头中必定有源端口号和目的端口号）
一.UDP协议
UDP协议格式
UDP协议采用定长报头(8字节)，将报头和有效载荷分离;
源端口号和目的端口号：表示数据从哪个进程来，到哪个进程去。
16位UDP长度：表示整个数据报（报头加数据）的最大长度；因为是定长报头(8字节)，所以数据长度 = 总长度 - 8
16位检验和：若检验和出错，会直接丢弃。
UDP协议特点——类似于寄信
1.无连接：不进行连接，只要知道对端的IP与端口号就可以直接通信。
2.不可靠：无确认机制；无重传机制；数据无有序保障；若因网络原因为把数据发送到对端，UDP协议也不会给应用层返回错误。
3.面向数据报只能整包发，整包读。不可能出现读一包半的情况。
UDP缓冲区
没有发送缓冲区，调用sendto会把数据交给内核，由内核再把数据交给网络层……
有接收缓冲区，但是：
1.不保证接受的顺序与发送的顺序一样；
2.如果接收缓冲区满了，在写入的数据会被丢弃。
UDP的socket为全双工，可同时读写。
二：TCP协议
TCP协议格式
源端口号和目的端口号：表示数据从哪个进程来，到哪个进程去。
32位序号和确认序号有三个作用：
1.请求确认机制；
2.保证数据按序到达；
3.通过序号可得治重复的数据，实现去重。
具体细节后面有详细说明。
4位头部长度：表示TCP报头有多少个4字节。最大为1111->15个4字节，也就是60字节（带选项）；默认为0101->5个4字节，也就是20字节（不带选项）。
————————————————————————————————————————
六位标志位：
URG：紧急指针（优先处理的字段）是否有效（有效为1，无效为0）
ACK：确认号是否有效
PSH：提示接收端应用程序立刻从TCP缓冲区读数据
场景：TCP有接收缓冲区和发送缓冲区，若应用层一直不读数据，客户端一直往应用层写数据，那么缓冲区可能满了，就像我蒙着眼给同学的杯子里倒开水一样，当接收缓冲区已经满了，通过PSH标志位提示应用层该读数据了
RST：如果三次握手时最后一次报文丢失，客户端会认为建立好了连接，然而服务器认为没有建立好连接，此时服务器给客户端一个RST响应，告诉客户端并没有建立连接。当客户端收到该响应：应重新建立连接或关闭老连接。（复位报文段）
SYN：请求建立连接，三次握手时为1（同步报文段）
FIN：通知对方本端要关闭，四次挥手时为1（结束报文段）
————————————————————————————————————————
16位窗口大小：就是本端接收缓冲区剩余的大小，要把剩余的大小给对端。
16位校验和：接收端校验不通过则认为数据有问题。
16位紧急指针：因为TCP保证按序到达，所以通过紧急指针标识哪部分为紧急数据，需要优先处理。
TCP连接机制
我在前一篇文章有非常详细的介绍，附链接：
https://blog.csdn.net/han8040laixin/article/details/81283399
TCP在具有可靠性的同时，也引入一些机制来提升效率，接下来我一一介绍：
①可靠性
校验和：接收端校验不通过则认为数据有问题。
连接管理：https://blog.csdn.net/han8040laixin/article/details/81283399
序列号：
TCP将每个字节的数据都进行了编号，称为序列号；
序列号保证了：
1.保证数据按序到达；
2.确认应答；
3.通过序号可得知重复的数据，得以去重；
确认应答（ACK）机制
比如我发了1-100的数据（按序到达），对端的确认序号就是ACK 101，表示101号之前的数据都已经确认。
超时重传机制
1.A主机给B主机发送数据之后，可能因为网络原因，数据丢包，没有到达主机B；若主机A在一个特定的时间间隔内没有收到B发来的确认应答，就会进行重发；
2.主机A没有收到B发来的确认应答，可能是因为该确认应答丢包，这时通过序号可以得知重复的数据，得以去重。
这个特定的时间间隔是动态计算的。2^n-1 * 500 (ms)，也就是说，第一次为500ms，再重发一次为500*2，再就是500*4,500*8……,累积到一定次数，TCP认为网络或对端有问题，直接关闭连接。
流量控制
接收端把自己的窗口大小告诉发送端，指明自己的接收缓冲区还剩多少；如果接收端的上层一直不处理数据，那么窗口大小就会一直变小，发送端就会减慢发送速度；当接收缓冲区满了，就将窗口大小设为0且告知发送端，这是发送端不再发送数据，但是会定时的发送一个窗口探测，探测接收端窗口大小。
拥塞控制
在对方能接收的前提下，我直接发送一万条数据，如果收到九千九百多条确认应答，应该是部分丢包；如果只收到几个应答，那一定是网络问题。
所以TCP使用慢启动机制，先发送少量数据，看看网络的拥塞状态，再决定以多大的速度传送数据。
拥塞窗口：
第一次发送，拥塞窗口为1，只发送一段数据；收到一个应答，变为2；此时一次发送两段数据，再收到这两段应答，滑动窗口变为4，一次发四个数据……这样就是以指数形式增加。
每次发送时，将拥塞窗口和对方窗口大小比较取小的值作为发送的滑动窗口。
当拥塞窗口增长到一个阈值，以线性增加。
②提高性能
滑动窗口
确认应答性能较差，因为对每一个发送的数据段，都要收到ACK应答才继续发送下一个，尤其是数据往返时间较长的情况。
如果一次发送多段数据：
虽然一次发送多段数据，但是一次发送的数据量是有限的；
滑动窗口：
16位窗口大小指的是接收端的接收缓冲区剩余的大小，我给你发数据，你要把你能接收的大小告诉我；
接收端把它接收缓冲区剩余大小告诉我了，所以这个大小就是我无需等待确认应答而可以继续发送的最大值，图里的窗口大小就是400字节。我要维护这个大小，发送前四段数据时，无需等待ACK，因为我知道你的接收缓冲区装得下，就算你一条没读，数据顶多塞满你的接收缓冲区。
收到第一条确认应答（ACK 101，滑动窗口往后滑），这时需要有一个发送端维护的发送缓冲区（由对端的接收缓冲区确定），记录哪些数据没有得到确认应答，而得到确认应答的数据段，就从发送缓冲区删除。
快重传
一次发送多段数据，如果丢包了，原因：
1.若是确认应答丢包了，不要紧，可以根据后面的应答确认接收端已经接受了多少数据。
2.如果是数据丢包了，就需要快重传机制。
举例，当101-200这段报文丢包，接收端没有接收到这段，就会一直给发送端发送ACK 101，表示我没有收到101；当发送端连续三次收到ACK 101，就会重发101-200的字段；这个时候接收端接收到101之后，再次返回的为ACK 501（在连续三次发送ACK 101时，接收端接收的其实是200 -301 301-400 401-500的字段，只是被放到了接收缓冲区）
延迟应答
接收端处理数据的能力可能很快，如果收到数据等一会再应答，那么等的这段时间，数据可能已经处理完了，那么返回的窗口大小就会比直接应答大，传输效率就会高。
一般每隔两个包，延迟200ms应答一次。
捎带应答
ACK搭顺风车，和数据放一起应答。就像捎东西的例子。