传输层协议有两款：TCP和UDP，下面我们来具体学习它们。
TCP：
TCP全称Transmission Control Protocol，传输控制协议。先给大家灌输一个概念：TCP是面向连接的传输协议。
我们思考一下，我们的电脑，或者手机，同一时间在运行的APP有很多，例如我们运行着QQ、微信、浏览器。那么在我们的电脑收发数据时，是怎么区分哪些是QQ的数据，哪些是微信的数据，哪些是浏览器的数据的？
答案就是：端口号。
例如，我们的图书馆中，有很多种类型的书籍。在放置书籍的时候，我们将图书馆进行区域的划分。1号区域放置历史类书籍，2号区域放置计算机类的书籍，3号区域放置数学类的书籍。我们可以通过编号，来区分书籍的类别。
类比一下，假如我们的QQ应用程序使用的1100号端口，微信使用2200号端口，浏览器使用80号端口，根据端口号，电脑就可以精确的区分开各个应用程序的数据流量了。
来看下电脑中的端口号信息：
和我们二层、三层地址类似，都有源和目的两个，传输层的端口号也要分为源端口和目的端口。
我们来看下TCP的报头中的内容：
16位源端口号：源主机的应用程序使用的端口号。
16位目的端口号：目的主机的应用程序使用的端口号。每个TCP头部都包含源和目的端的端口号，这两个值加上IP头部中的源IP地址和目的IP地址可以唯一确定一个TCP连接。
32位序列号：用于标识从发送端发出的不同的TCP数据段的序号。数据段在网络中传输时，它们的顺序可能会发生变化；接收端依据此序列号，便可按照正确的顺序重组数据。
32位确认序列号：用于标识接收端确认收到的数据段。确认序列号为成功收到的数据序列号加1。
4位头部长度：表示头部占32bit字的数目，它能表达的TCP头部最大长度为60字节。
16位窗口大小：表示接收端期望通过单次确认而收到的数据的大小。由于该字段为16位，所以窗口大小的最大值为65535字节，该机制通常用来进行流量控制。
16位校验和：校验整个TCP报文段，包括TCP头部和TCP数据。该值由发送端计算和记录并由接收端进行验证。
TCP工作过程：
前面给大家提到，TCP是面向连接的协议，因此，在双方通信之前，需要先建立TCP的连接。就像是我们给别人打电话，电话必须先拨通之后，我们才可以互相说话。
TCP连接建立过程：
我们假设服务器A是百度的服务器。主机A打开百度网页，其中TCP的建立就像上面的交互过程。
首先，主机A主动打开百度网页，主机A系统后台向服务器发起TCP的建立连接请求。请求报文中，TCP报头中的SYN位将会被置1，表示这个报文是一个建立请求的报文。Sequence Number字段将会被设置一个序号值，假定这个序号为0；
服务器收到主机A的请求之后，会向主机A回复，告知主机A同意建立连接。服务器发送的报文，TCP报头中，SYN位同样会被置1，并且ACK位也会被置1。这样表示服务器同意了主机A发起的建立连接请求。同时，Sequence Number字段将会被设置一个序号值，假定这个序号为0，并且Acknowledge Number也会设置一个值，这个值是主机A发送的请求报文中Sequence Number的值加一，表示收到了主机A发送的TCP报文。
主机A收到服务器的请求确认报文之后，会再次回复服务器一个确认报文，表示自己收到了服务器的请求确认报文。这一步是是必要的，如果没有最后这一步的确认，我们称建立的TCP连接为半连接状态。DDoS攻击的方式就是向目标服务器发起大量的半连接，以此来消耗服务器的资源，使服务器无法给正常的客户端提供服务。
经过三次交互，TCP连接建立完成，我们形象的称为三次握手。
举个例子，张三给李四打电话：
张三：“喂~可以听到我说话吗？”--------------------------（主机A向服务器发送SYN置位的TCP连接建立的请求报文）
李四：“可以听到，请讲。”----------------------------------（服务器收到主机A的请求报文之后，对主机A回复确认，表示自己已经收到对方的请求报文，并同意建立TCP连接）
张三：“好的，那我开始说我的事情了。”----------------（主机A最终确认服务器已经同意建立TCP连接。至此，TCP连接建立完成，后续就开始传输数据）
TCP连接建立完成之后，后续就开始了数据传输的过程
例如上面的例子。主机A向服务器发送连续的数据段，服务器收到主机A发送的数据之后，会对主机A发送确认报文。为了避免高频率的确认带来的额外的网络开销，服务器会在收到若干数据段之后，对接收到的数据段进行统一的确认。
我们假定上面例子中M=0。
第一次发送，主机A连续发送三次，每次发送500份数据，共计发送了1500份数据，序号为0-1499
服务器收到主机A发送的1500份数据之后，对主机A进行统一的确认，确认号为1500，即上次主机A发送的最后一份数据的序号+1，也可以理解为，服务器告诉主机A，下次发送的时候从序号为1500的地方开始继续发送
正常的数据交互，都会按照上面的步骤进行。
若中间出现了数据丢失的情况，服务器会要求主机A重新从未能接收到的地方重新传输，例如：
主机A第二次发送数据，和第一次一样，连续发送三次，每次发送500份数据，共计1500份
服务器接收数据时，序号为1500的数据没有接收到，服务器向主机A回复确认时，会按照最后接收到的数据序号+1作为确认号进行回复，也可以理解为，服务器要求主机A从自己的确认号的数据开始发送
主机A重新从序号为1500的数据开始发送
TCP滑动窗口机制
TCP的滑动窗口机制，是用来控制TCP流量大小的，具体过程如下
例如上面的例子。首次传输，主机A尝试先按照一次传4096份数据的速度进行传输，此时窗口大小为4096
服务器A接收主机A发送过来的数据，由于服务器的缓存区无法完全容纳4096份数据，主机A发送的最后1024份的数据没能接收，于是向主机A回复确认，确认号为自己接收到的最大序号+1，即1024*3+1=3073，同时告知主机A，窗口大小要调整为3072，即一次只需传输3072份数据即可
主机A收到服务器的确认之后，得知服务器A的窗口大小为3072，就会按照服务器窗口大小进行发送数据，每次发送3072份
TCP关闭连接过程
在数据发送完成之后，主机和服务器之间的TCP连接需要关闭，释放系统资源。TCP连接关闭的过程如下
主机A发送完数据之后，会向服务器发送FIN和ACK都置位的TCP报文，表示自己数据发送完成，请求关闭TCP连接。
服务器收到主机A的关闭连接请求之后，会回复主机A确认自己收到了对方的请求。
同时，服务器A也会向主机A发送FIN和ACK都置位的TCP报文，告诉主机A自己也要关闭连接；
主机A收到服务器的关闭连接请求之后，也会向服务器回复确认，表示自己收到了对方的请求。
提问：为什么服务器还需要向主机A发送关闭连接的请求报文？前两步的交互不是已经关闭连接了吗？
是因为主机和服务器，双方各自维护着自己的TCP连接表项，因此关闭连接时，双方都需要将自己表项中的TCP连接进行关闭，因此就出现了双方互相发送请求并确认的情况。
经过四次交互，TCP连接完全关闭。我们形象的称为四次挥手。
UDP：
UDP全称User Datagram Protocol， 用户数据报协议。
我们先来看下UDP的报头信息。
相比较TCP而言，UDP的报头字段精简了非常非常多。仅仅只有源端口、目的端口、长度、校验和四个字段。由于没有序号和确认号字段，因此像TCP中的确认重传机制，在UDP协议中，仅靠UDP是无法完成的。
提问：这里没有了确认和重传机制，那么数据传输时丢失了怎么办？
虽然UDP协议无法提供确认重传机制，但是应用程序开发人员可以在应用程序中内置确认和重传机制，通过应用层协议来完成确认重传的操作。以此保证数据传输的完整。
在我们看来，UDP少了确认和重传机制，协议变得”糟糕“了。其实不然，正因为少了确认重传的过程，使得UDP在数据传输时效率很高。因为不需要对每一段的数据进行确认，也就降低了传输的延时，对于一些时延敏感的流量，UDP是更好的选择。
举个例子。我们打电话时，或者看直播时，其实就是采用了UDP的协议进行传输的。因为我们打电话，看直播，对延迟的要求比较高，不能有很明显的延时存在。假如说我们打电话，每次说完一句话，对方需要过一点时间才能收到，这就影响了我们通信的效率。并且，即便发生了数据丢失了一个两个，最多造成的就是我们某一句话漏了一个字两个字。这对于我们通话影响并不大，如果实在没听清，可以口头要求对方重新说一遍。这其实也是重传机制，只不过重传机制由我们通话的人提供了。
原文：https://www.cnblogs.com/ylkang/p/14760647.html