HCIA-传输层协议
Posted 丨Kang
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了HCIA-传输层协议相关的知识,希望对你有一定的参考价值。
传输层协议
传输层协议有两款: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的协议进行传输的。因为我们打电话,看直播,对延迟的要求比较高,不能有很明显的延时存在。假如说我们打电话,每次说完一句话,对方需要过一点时间才能收到,这就影响了我们通信的效率。并且,即便发生了数据丢失了一个两个,最多造成的就是我们某一句话漏了一个字两个字。这对于我们通话影响并不大,如果实在没听清,可以口头要求对方重新说一遍。这其实也是重传机制,只不过重传机制由我们通话的人提供了。
以上是关于HCIA-传输层协议的主要内容,如果未能解决你的问题,请参考以下文章