文章目录
1:传输层的作用
传输层是负责数据能够从发送端的进程发送到接收端的进程的！即应用层的应用根据应用层的协议将数据封装好后，通过操作系统协议栈将数据委托给传输层进行发送。
2：再谈端口号
传输层能保证数据在网络上两台计算机的不同的程序进行通信，肯定需要一个东西来识别不同的应用进程，因为计算机收到数据之后，肯定要交给相应的进程，所以需要一个东西来进行识别，这个东西就叫端口号。
3:UDP协议
3.1UDP协议格式相关字段说明
1.源端口：绑定发送端的进程。
2.目的端口：绑定目的端的主机的进程。
3.16位UDP的长度：表示整个数据报(UDP首部+UDP数据）的最大长度。
4.16位UDP校验和：用于校验数据是否出错，如果校验和出错，这个数据报就会直接丢弃。(类似文件的MD5）
相关说明图解：
3.2UDP协议的特性
基于以上对UDP的理解,不难发现它有一下特性：
1:无连接，不可靠(要保持连接的话,通信双方要保持一个连接的状态）
2:面向数据报(发送和接收数据都一次完成，如果是大数据被网络层切分的话，那么会增大数据的丢失可能性）
3:有接收缓冲区，没有发送缓冲区(发送方不关心接收方有没有接收到数据）
4:发送数据的大小受限制(最多64K)
4:TCP协议
4.1:TCP协议格式相关字段说明
1:源端口号和目的端口号:表示数据的发送方进程和接受方进程
2:32位序号/32位确认序号:TCP最终是依托字节流传输的，因此TCP会将字节数据进行编号，32位的序号就是该报文首字节的编号;而确认序列号就是告诉发送方下一个要发送的字节报文序号；
3:4位TCP报头长度:表示该TCP头部有多少个32位bit的长度；
4: 6位标志字段:ACK=>确认号是否有效(回复)；PSH==>提示接收方程序立刻从TCP缓冲区把数据读走；RST==>对方要求重新建立连接;我们把携带RST标志的称为复位报文段；SYN==>请求建立连接，我们把携带SYN标识的称为同步报文段；FIN==>通知对方,本端要关闭了，我们称携带RIN的为结束报文段
5:16为窗口大小:该报文字段用于流量控制，该字段用于表示接收方愿意接受的字节数量；
6:16为校验和：发送端填充, CRC校验. 接收端校验不通过, 则认为数据有问题. 此处的检验和不光包含TCP首部, 也包含TCP数据部分
7:16位紧急指针:标识那部分数据是紧急数据
4.2:TCP传输的安全性和可靠性机制
4.2.1确认应答(ACK)机制
4.2.2超时重传机制
说明：
1: 在主机A向主机B发送数据时可能丢包，依照TCP协议在特定的时间内若A没有接收到B的确认应答，A就会重发数据包，也有可能是却仍应答丢包了，导致A没有收到，A也会重发数据包，这样就导致了B收到了很多重复的数据包，不过不用担心，数据包中的序号这时就起作用了，我们可以轻松的把相同序号的数据包去除就可以了。
2:超时的时间如何确定？
这个时间是动态计算的，首先会以一个比较折中的时间为超时等待时间(500ms)，若在这个时间内还没有收到应答回复，重发一次，继续等待(2500ms),若还等不到就重发一次，再等待(4500ms),直到等待一定时间；还收不到应答，此时就判断对方主机异常，强行关闭连接！
4.2.3连接管理机制(TCP三次握手与四次挥手）
4.2.3.1TCP三次握手建立连接
过程：
1:首先客户端会发送一个特殊的TCP报文,这个报文不含有用户数据，在报文中会把SYN置为1，另外会随机选择一个序号seq(假设为j),之后客户端会进入SYN_SENT状态(同步已发送状态）
2:服务器在接收到客户端发来的请求连接报文后，会向客户端发送应答报文，其中SYN置为1，ASK=j+1,seq=x(假设为x)这报文称===》SYNACK报文，表示同意该连接；服务端将进入SYN_RCVD状态(同步收到状态）。
3:客户端在收到服务端的应答后就进入ESTALISHED(已连接状态)，并再次给服务端应答，其中SYN=0,ASK=x+1,seq=j+1;服务端接收到ACK响应后也就进入了ESTALISHED(已连接状态)；此后就可以通信了！
!补充说明之TCP为什么是三次握手，两次不可以吗？
首先要明白的是握手建立连接是可以，但是会产生不必要的错误和浪费资源；首先可以考虑一个这样的场景：当客户端发送一个SYN请求连接报文后,在一定的时间内没有接收到响应报文,这时客户端TCP可能会认为丢包了，从而来个超时重传，实际上这个请求连接的数据包可能是因为网络拥塞，被堵在路上，并没有发生丢包，当客户端与服务端建立连接传输数据，关闭连接后;此时这个之前被认为”丢包“的请求数据，网络畅通后，就到达了服务器，由于使用两次握手的机制，服务端给出响应后，服务端和客户端又建立连接了，这样不就是白白浪费系统资源吗？而采用三次握手就没有这样的问题，服务端接收到那个滞留的请求连接包后，发送响应报文给客户端，但是之前已经确认应答收到过此数据包，客户端的TCP就不会进入下一个状态ESTALISHED(已连接状态)，并且不会给服务端做出响应回复，服务端没有收到回复，自然也不会进入连接状态，所以TCP三次握手是必要的！
4.2.3.2一个通俗的场景帮助理解TCP三次握手的过程
可以类比一个男孩向女孩求婚的过程：
4.2.3.3TCP四次挥手断开连接
过程:
1:以客户端发送释放连接为例，首先客户端发送一个释放连接的报文,其中FIN=1,seq=x;并且客户端不再发送数据，进入FIN-WAIT-1(终止等待1)状态。
2:服务端接收到释放连接的报文后;自动发送ACK应答报文给客户端，ACK=x+1,seq=v，然后服务端应用进程，客户端不再发送数据了，但是我服务端还可以发送数据，所以就进入CLOSE-WAIT（关闭等待）状态。
3:客户端接收到服务端的ACK应答报文后，将进入IN-WAIT-2(终止等待2)状态;等待服务端发送释放连接报文，服务端在发送完最后数据后，将发送一个FIN释放连接报文，其中FIN=1,seq=w;然后服务端将进入LAST-ACK（最后确认)状态；等待客户端的响应。
4:客户端收到释放连接报文后，将发送ACK应答报文，ACK=w+1,seq=j,然后客户端将等待2MSL后关闭连接，服务端接收到以后也就关闭连接了。
！客户端为什么不直接设置CLOSED关闭连接，要有个等待时间能？
因为给服务端的ASK响应可能丢包，为了让服务端及时收到响应设置这个等待时间就是为了能超时重传，这样即使给服务端的ASK响应包丢了，在这个等待时间内也是能重发数据包的。
！为什么建立连接是三次握手，关闭连接确是四次挥手呢？
建立连接为什么是三次，上面已经做出了说明，而关闭连接为什么是四次，这是因为系统对于TCP协议实现时，接收到了FIN，不用执行应用程序的代码，而是系统会自动返回一个ACK响应,意思是你发送了FIN仅仅只能代表你不在发送数据了，而我可能还要给你发送数据，至于我什么时候给你发送FIN,这取决于应用层的代码(服务端在关闭连接时可能还有一些操作，如刷新缓冲区等等）；这样一来便自然比建立连接时多了一次。
4.2.4流量控制机制(安全机制）
接收端处理数据的速度是有限的，如果发送端发送数据太快，导致接收端的缓冲区爆满的话，这个时候如果发送方继续发送数据，就会造成大量的丢包，继而会引起一系列重传数据包问题，这样是非常不好的也影响效率。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制叫流量控制。
4.2.5拥塞控制机制(安全机制）
一开始发送端并不清楚网络状态时，会采取慢启动机制，先发少了的数据包去探探路，根据反馈再来决定发送数据的速度。
4.2.5.1 TCP 发送方如何限制它向其连接发送流量的速率呢?
首先TCP连接的每一端都是由一个接收缓冲区，和发送缓冲区，还有几个变量组成。有一个变量叫拥塞窗口，TCP通过跟踪这个变量就可以限制发送方的效率；拥塞窗口表示为cwnd,它限制了在发送方未被却仍应答的数据不会超过cwnd,通过调节cwnd的值即可控制发送方的发送效率。
4.2.5.2 TCP 发送方如何感知从它到目的地之间的路径上存在拥塞呢？
第一种:当发生丢包事件时，这意味着网络拥塞，此时应该减小发送方的拥塞窗口长度。
第二种:一个确认报文交付给发送方时，对之前的发送报文进行确认时，将会提高发送方的发送效率。
第三种:带宽探测，发送方以先一定的速率发送数据包，然后适当的提高速率，若没出现丢包，则增加发送速率，若出现丢包，则适当的减小发送速率。
4.2.5.3 当发送方感知到端到端的拥塞时，采用何种算法来改变其发送速率呢？
采用的是广受赞誉的TCP拥塞控制算法，主要有三部分组成：慢启动、拥塞避免、快速恢复组成。
慢启动:是指发送方不知到网络是否拥塞的情况下,先以一种较低的发送速率发送数据包;然后以2的指数增长拥塞窗口的值，提高发送速率。(===>可以理解为探路）
拥塞避免：当出现三个冗余的ASK响应时，则判断为丢包，此时以2的因子来减少拥塞窗口的长度。
快速恢复:当响应的ACK每次都能快速响应时，此时发送方的拥塞窗口长度又会以2的指数来增长，从而快速提高发送速率。
4.3:TCP传输提高效率机制
4.3.1滑动窗口机制
在多线程并发的情况，并发发送数据，可以提高网络的数据传输速率。
滑动窗口的大小，就是无需确认应答，可以发送的数据最大值。它还受限于(拥塞窗口和16为窗口大小)min的限制。
4.3.2延迟应答机制
接收端在接收到数据后，不会急于ASK响应，会稍微停留一定时间，这样接收方就有相对更多的时间来处理接收缓冲区的数据，流量窗口的大小将会相应的变大，这样就有利于提高数据传输的速率。
4.3.3捎带应答机制
在TCP三次握手时，第三次客户端的响应ASK就可以携带数据，这样也会提高数据传输速率的；其机制就是将有些ASK响应和发送的数据合并在一起。
4.4粘包问题
TCP协议是依托字节流的，有接收数据和发送数据的缓冲区，如果在解析某个数据时，用到了其他部分的数据，这样就产生了数据粘包。解决粘包问题就是在应用层自己约定好数据格式，怎样读取解析缓冲区的数据，这样就明确了数据包之间的边界，从而避免粘包。
5:对比TCP与UDP协议
1.UDP是面向数据报，无连接，不可靠，但是效率高，因为没有ASK应答这些机制；TCP是面向字节流的，有连接，是可靠传输，效率相对低一些。
2.UDP只能一次发送数据和一次接收数据；TCP面向的是字节流，可以多次接收与发送。
3.UDP只有接收缓冲区；TCP有接收缓冲区和发送缓冲区。
4.UDP数据大小受限制，而TCP则不受限制(因为是面向字节流，可以多次接收和发送数据）。