计算机网络——传输层
文章目录
计算机网络——运输层
概述和运输层服务
运输层和网络层的关系
首先,运输层会将应用层报文进行分块(应用层报文小的话不会分块),然后将分成的块加上运输层首部信息并编以号码,然后发送给位于其之上的网络层。
经运输层处理过后的报文称之为报文段。
网络层将运输层发送的报文段封装成数据报传递给数据链路层,网络路由器仅作用于数据包的网络层字段,不对运输层字段进行检查。
网络层位于运输层之上,为不同的主机之间提供逻辑通信;而运输层为不同主机上的不同进程提供逻辑通信。
正是因为网络层位于运输层之上,因此运输层协议能够提供的服务常常受制于网络层协议的服务模型。如,若网络层不提供时延和带宽保证的话,运输层就不能保证时延和带宽保证。
运输层概述
运输层协议为运行在不同端系统上的应用进程之间提供了逻辑通信功能。即应用层协议直需要告诉运输层要发送的内容,具体的传输过程由运输层来实现。
运输层协议分为两种:TCP协议和UDP协议。每种协议都能为调用的应用程序提供一组不同的运输层服务。
- TCP协议(传输控制协议):为调用它的应用程序提供可靠的、面向连接的服务
- UDP协议(用户数据报协议):为调用它的应用程序提供不可靠的、无连接的服务
RFC文档中将TCP协议的运输层分组称为报文段,而将UDP协议的运输层分组称为数据报,但是将网络层的分组也称为数据报,因此,此文中将TCP协议分组和UDP协议分组统称为报文段。
IP协议尽力而为地交付服务,即它尽最大的能力交付报文段,但是不保证报文段的按序交付,也不保证报文段中数据的完整性。因此IP协议被称为不可靠服务
UDP和TCP的基本职责是:将两个端系统间IP的交付服务扩展为端系统上两个进程的交付服务,称之为运输层的多路复用和多路分解。
UDP和TCP可以通过在其报文首部中包括差错检查字段而提供完整行检查。
进程之间的数据交付和就差错检查是两种最低限度的运输层服务,也是UDP仅有的服务。
TCP还提供可靠数据传输和拥塞控制。
- 通过使用流量控制、序号、确认和定时器来确保正确的、按序的将数据从发送进程交付给接收进程
- TCP通过调节控制TCP连接的发送进网络的流量速率来实现拥塞控制。TCP拥塞控制防止任何一条TCP连接用过过多流量来淹没通信主机之间的链路和交换设备,力求为每一条通过一条拥塞网络链路的连接平等地共享网络链路带宽。
端口号
定义
MAC地址用来表示同一链路中不同的计算机
IP地址用来表示网络互联中的主机和路由器
端口号用来识别同一台计算机中不同的应用程序,因此也被称为程序地址。
通过IP地址、端口号、协议号进行通信识别
- 端口号不同
- 端口号相同
- IP地址相同
- 协议号(表示上层是TCP还是UDP的一种编号)相同
- 协议号不同
- IP地址不同
- IP地址相同
- IP地址不同,端口号相同
- 网络通信中通过源IP地址、源端口号、目的IP地址、目的端口号、协议号来唯一标识一个通信,只有当这五个值完全相同时,才会被认为是同一个通信,否则会被认为是两个不同的通信
端口号的确定
端口号是一个16比特的数,大小在0-65535之间
- 0-1023范围内的端口号不能使用,被称为周知端口号或者知名端口号,已经被其他周知的应用程序所使用,如邮件服务器的25号端口和web应用程序的80端口号以及FTP的21端口号
- 1023-49151之间的端口号可能被正式注册,但是这些端口号可用于任何通信用途
- 49152-65535之间的端口号为操作系统动态分配的端口号
端口号与协议
端口号由其所使用的协议决定
不同的协议可以使用相同的端口号,但使用目的不同,因为端口号上的处理是根据每个传输协议的不同而进行的
知名端口号与传输层协议没有关系,只要端口一致都分配同一种程序进行处理
多路复用和多路分解
将运输层报文段中的数据交付到正确的套接字的工作称为多路分解
在源主机从不同的套接字中接收报文并将报文进行封装处理生成报文段,然后将报文段传递到网络层的工作称为多路复用
要求:
- 套接字由唯一标识符
- 每个报文段由特殊字段来只是该报文段要交付到的套接字,如,源端口号字段,目的端口号字段。
UDP套接字是由一个二元组全面标识的,该二元组包含一个目的端口号和源端口号。
而TCP套接字是由一个四元组全面标识的,该四元组由目的IP、目的端口号、源IP、源端口号构成。
源端口号的作用:在由A到B的报文段中作为源端口号,然后当B向A返回报文中作为目的端口号。请求报文和回应报文中目的端口号和源端口号互换。
只要目的IP地址和目的端口号相同,这两个报文段就会通过相同的目的UDP套接字而被定为到相同的进程;
只有当源端口号、源IP、目的端口号、目的IP都相同时才会被相同的TCP套接字接收从而被定位到相同的进程,否则会由两个不同的TCP套接字接收而被定位到两个不同的进程。
UDP
简介
UDP不提供复杂的控制模式,利用IP提供面向无连接的通信服务,接收数据后立即发送
不具有可靠性,可以确保发送消息的大小,但是不保证数据一定会到达接收方
典型应用:
- 包总量较少的通信(DNS、SNMP等)
- 视频、音频等多媒体通信(即时通信)
- 限定于LAN等特定网路中的应用通信
- 广播通信(广播、多播)
UDP报文
UDP报文由报文首部和数据组成,数据部分为应用层报文
UDP报文首部解析:
- 源端口号:发送端应用的端口号,字段长16位。该字段也可能不设置,此时为0,用于不需要返回的通信中
- 目的端口号:接收端应用的端口号,字段长16位。该字段的值必须设置。
- 包长度:首部长度+数据部分长度,单位为字节
- 校验和:为了提供可靠性数据传输而设计,用来进行差错校验。每16位数据相加之和的结果的反码作为校验和。UDP伪首部、UDP首部、UDP数据都算。超出16位会进行回卷操作。
- 接收端可以通过校验和来检验数据的完整性和正确性。将UDP伪首部、UDP首部、UDP数据以16位为单位进行相加,将检验和与该结果按位相与的结果应该全为1,若不全为1则证明数据错误。
- UDP伪首部
TCP
特点
- 面向连接的、可靠的流协议,流即不间断。
- 可以进行丢包时的重发控制
- 对乱序的分组进行顺序控制
- 只有确定通信对端存在时才会发送数据、从而控制通信流量的浪费
- TCP通过检验和、***、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输
TCP要理解的内容:可靠性传输,流量控制,拥塞控制。
TCP报文
TCP报文由TCP报文首部+数据部分构成。数据部分为应用层报文
TCP报文首部解析:
-
源端口号:发送端应用端口号,长度为16位
-
目的端口号:接收端应用端口号,长度为16位
-
***:字段长32位。指发送的位置,每发送一次数据包,大小加上发送的数据包大小。
***由建立连接时计算机生成的随机数作为其初始值,每发送一次数据,就会累加一次数据的大小
在建立连接和断开连接时发送的SYN包和FIN包虽然并不携带数据,但是也会作为一个字节增加对应的***
-
确认应答号:长度32位。指下一次应该接受到的数据的***。
发送端可以根据接受到的确认应答来判断之前发送的数据是否被正确接受
-
数据偏移:表示所传输的数据部分应该从TCP包的哪个位开始计算,也可以看做TCP首部的长度。长度4位,单位大小为4字节。比如,若该值为5,则TCP首部长度为20字节,真正的数据内容从21字节开始
-
保留:长度为4位,一般设为0,主要为了拓展用
-
控制位:长度为8位,从左至右分别为:CWR、ECE、URG、ACK、PSH、RST、SYN、FIN
- CWR:和ECE用于IP首部的ECN字段。ECE标志位为1时,通知对方将拥塞窗口缩小
- ECE:在收到数据包的IP首部中ECN为1时将TCP首部中的ECE设置为1
- URG:为1时表示 需要紧急处理的数据
- ACK:为1时确认应答字段变为有效。除了最初建立连接时的SYN包之外该位必须设置为1
- PSH:为1时表示需要将收到的数据立即传给上层应用协议;为0时不需要立即串而是先缓存
- RST:为1时表示TCP连接中出现异常必须强制断开连接
- SYN:用于建立连接。为1时表示希望建立连接,并在其***的字段进行***初始值的设定
- FIN:为1时表示之后不会再有数据发送,希望断开连接。主机收到FIN包后不必马上回复一个FIN包,而是可以等待缓冲区中的所有数据都已成功发送而被自动删除后再重发
-
窗口大小:长16位,用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小。若窗口大小设置为0,则代表窗口探测,数据必须使1字节。
-
校验和:和UDP校验和类似,但是TCP校验和无法关闭
校验和主要是为了检测数据包在路由器中遇到的错误,数据链路的FCS检查是为了检测传播途中出现的错误
-
紧急指针:长16位。只有在URG控制位为1时有效,紧急指针指出了紧急数据的末尾在报文段中的位置(从数据开头开始),一般在暂时中断通信或中断通信时使用。
-
选项(长度可变):用于提高TCP的传输性能。最大为40字节,应尽量调整为32的整数倍。可用于填MSS。
-
填充:
通过***和应答机制提高可靠性
每当通信方接收到一个正确的数据包时,会发送一个ACK包,即应答机制。若有确认应答,证明数据已到达通信对端,在一段时间之内没有收到确认应答时,会重新发送数据包。此为超时重发。
发送端未接收到确认应答的几种情况:
- 发送数据未到达接收端
- 接收端接收到发送端的数据后,返回的ACK包在传输途中丢失
TCP会对分组的每个字节进行编号,接收端通过查询接收数据TCP首部中的***和数据的长度自己下一步接受的 序号作为确认应答返回回去,就这样通过***和确认应答机制实现可靠传输
TCP的数据长度并未写在TCP首部中,而是通过IP包大小-IP首部计算而出
TCP如何保证可靠性
-
停止等待协议:没法送完一个分组,就停止发送等待对方的应答,收到确认后再发送下一个分组
- 确认丢失:确认应答包在传输过程中丢失
- 确认迟到:确认应打包在超时时间内未发送到发送方。
-
连续ARQ协议:利用发送窗口,位于窗口的所有分组都可以连续发送出去,而不需要等待对方的确认。A没收到一个确认,就把发送窗口向前滑动一个分组的位置。B采用累积确认方式,对按序到达的最后一个分组发送确认,就表示这个分组之前的分组都收到了
-
具体内容:
- 以字节为单位的滑动窗口。
-
白话总结:
TCP以字节为单位的滑动窗口保证数据传输的可靠性,TCP会为每个字节都进行编号,并且对数据包进行确认应答,即每次收到数据包之后就会发送一个ACK包通知对方自己已经收到发送的内容,发送方和接受方都会维护一个缓存区,将数据按照编号顺序将数据放入缓冲区,然后按顺序发送(发送滑动窗口内的数据),若接收方返回一个确认应答包时,发送方会将滑动窗口向前移动并将已经确认送达的数据从缓冲区中移除。若中间的某段数据丢失,接收方会向发送方发送一个SACK包,以告知哪段数据丢失需要重发。
重发超时时间(RTO)的确定
TCP为每一个数据包都设置了一个超时定时器,在超时定时器结束时都没有收到确认应答包就认为分组丢失,进行重传,若收到,则取消超时定时器。
每次发送数据前都会重新确定重发超时时间,重发超时时间由往返时间及其偏差共同确定。
因为每次通信的距离不确定,以及通信链路也不确定,网络环境对往返时间也会产生影响,因此每次发送数据前都会重新进行确认。
在Unix以及Windows系统中,超时都是以0.5秒为单位进行控制,而在第一次发送数据时不能确定重发超时时间,因此一般设置为6秒
当数据重发之后还是收不到确认应答时,他会继续重发,并将应答时间按2的指数函数延长,当达到一定重发次数时,数据不会被重发,此时连接会被强制关闭,并通知应用程序应用通信异常强行终止
注意:
- 发送方在发送完一个分组后,必须暂时保留已发送的分组,只有在收到相应的确认应答后才能清楚保存的分组。
- 分组和确认分组都必须进行编号,来明确哪个发出去的分组收到了确认,哪个分组没有收到确认
- 超时时间应当比数据在分组传输的平均往返时间更长一些。
- 新的RTTs=(1-a)×旧的RTTs+a×新的RTT样本。RTTs为加权平均往返时间,RTTs的初始值为RTT样本推荐a=1/8
- 新的RTTd=(1-b)×旧的RTTd+b×|RTTs-新的RTT样本|。RTTd为RTT的偏差的加权平均值推荐b=1/4
- RTO=RTTs+4×RTTd
连接管理(三次握手四次挥手)
三次握手
三次握手指建立一个TCP连接时客户端和服务器端需要发送三个包;目的是连接服务器指定端口,建立TCP连接,并同步连接双方的蓄力可好和确认好并交换TCP窗口大小信息
第一次握手:客户端发送一个SYN包(SYN=1,ACK=0,Seq=X)指明要连接的端口号请求建立TCP连接
第二次握手:当服务器接收到客户端的SYN包时,会向发送端返回一个ACK包(SYN=1,ACK=1,Ack=X+1,Seq=Y)作为应答
第三次握手:当客户端接收到服务器返回的ACK包后会向客户端再发送一个ACK包(ACK=1,SYN=0,Ack=Y+1,Seq=Z)作为应答
四次挥手
四次挥手指断开一个TCP连接时客户端和服务器需要发送四个包;客户端和服务器均可主动发起挥手过程。
第一次挥手:当要断开连接时,主动方会向被动方发送一个FIN包(FIN=1,Ack=Z,Seq=X)请求断开连接
第二次挥手:被动方接收到FIN包后会发送ACK包(ACK=1,Ack=X+1,Seq=Z)作为FIN包的应答
第三次挥手:接着被动方会再发送一个FIN包(FIN=1,Ack=X,Seq=Y)请求断开连接
第四次挥手:发送端接收到之后会发送ACK包(ACK=1,Ack=Y+1,Seq=X)作为对FIN包的应答
TCP以段为单位发送数据
在建立TCP连接时,也会确定发送数据包的单位,称为最大数据长度(MSS),TCP以MSS为单位对应用层报文进行分割发送,MSS由客户端和服务器端共同确定,第一次握手时客户端会在ACK包中写上自己能发送的MSS,第二次握手时服务器会在返回的SYN包中写上自己能接受的MSS,最终以两者之中的最小值作为MSS的值,之后发送的数据也会以MSS为单位发送数据
MSS默认值为536字节。
TCP有三种不同的传输机制:
- 发送缓存中每达到一个MSS大小发送一次
- 由发送进程指明要发送报文段
- 发送方的设置一个计时器期限,期限一到就发送。
利用窗口控制提高速度
正常情况下TCP以一个段为单位,每发一个段都进行一次确认应答处理,但是这样就会造成时间上的浪费,导致通信性能的降低,因此TCP引入了窗口控制来解决这个问题
客户端不再是发出一个数据包后接收到该包的确认应答才会继续发送下一个包,而是直接发送,除非达到窗口大小,分组发送是按照分组序号从小到达进行发送的。
接收方采用累计确认的方式。即接收方不必对收到的分组诸葛发送确认,而是对按序到达的最后一个分组发送确认,表示到这个分组为止的所有分组都已正确收到了。
窗口大小指无需等待确认应答而可以继续发送数据的最大值,后面还会根据拥塞窗口的大小一起限制。
窗口控制机制导致客户端和服务器都维持了一个缓冲区,发送端主机在等到确认应答之前,必须在缓冲区中保存该包(因为只有接收到确认应答,才能确定数据已经完整到达接收端),当发送端主机接收到确认应答之后,该窗口会后移,此时就可以发送下一个数据包了,即只要数据包位于窗口内时,就可以发送该数据包,否则不能发送
比如,若窗口大小是四个段大小时,最开始客户端会连续发送四个数据包,此时它会达到最大窗口大小,然后每当他接收到一个确认应答时,就会再次发送一个数据包。
窗口控制与重发控制
在窗口控制中,如何处理数据丢失的情况?分为两种情况:
-
数据包已经到达接收端,接收端返回的确认应答在发送途中丢失:当他的下一个数据包到达接收端时,接收端会向发送端请求接受到的数据包的下一个数据包,此时发送端就会清楚接收端已经接收到该数据包了,就不需要重发
窗口在一定程度上够大时,既是由少部分确认应答丢失也不会进行数据重发,因为可以通过下一个确认应答进行确认
-
数据包未到达接收端:此时接收端会重复发送该数据包的确认应答,只要发送端接收到三个该包的确认应答时就会认为该数据宝丢失,然后会重发该包,称为高速重发控制
接收端再没有收到自己期望序号的数据时,会对之前收到的数据进行确认应答。发送端接收到三个该包的确认应答时就会认为该数据包丢失,然后会重发该包,称为高速重发控制
-
Nagle算法规定,当到达的数据达到窗口的一般大小或者已达报文段的最大长度时,就立即发送一个报文段。
流量控制
让发送方根据接收方的实际接受能力控制发送的数据量,称为流量控制。流量控制是指点对点通信量的控制,流量控制做的事就是抑制发送端的发送数据,保证接收端可以正常进行处理。TCP在每次进行发包的时候都可以根据自己的接受能力指定滑动窗口的大小来进行协调。
- 接收端向发送端主机告知自己可以接受数据的大小,然后发送端会发送不大于此限度的数据,即之前提到的窗口大小,窗口大小在每次发送数据的时候都可以重新进行调整。
- TCP首部中有一个字段专门用来存储该值,该值越大,说明网络的吞吐量越高
- 当接收端的缓冲区面临数据溢出时,窗口大小的值也会随之改变,从而进行数据发送量的控制
- 当接收端将窗口大小置为0时,发送端会暂时停止发送数据,直到接收端发送窗口更新通知,当过了重发控制时间之后,接收端还没有发送窗口更新通知,发送端就会发送一个窗口试探的数据段(只包含一个自己以获取最新的窗口大小信息)来决定是否可以继续发送数据
流量控制过程:
TCP如何进行拥塞控制
拥塞即指供不应求,当网络拥堵时,有一个主机突然发送大量数据到网络中,就会造成网络的瘫痪,因此TCP引入了拥塞控制机制。拥塞控制机制就是防止过多数据进入网络中,这样使网络中的路由器或者链路不至于过载。
不进行拥塞控制的话整个网络的吞吐量将会随输入负荷的增大而下降。
TCP中有一个拥塞窗口的概念,当拥塞窗口大小小于慢启动阀值时采用满启动算法,大于时采用拥塞控避免算法,等于时两者皆可。当发生超时重传,即网络发生拥堵的时候,将慢启动阀值更新为发生拥塞时的一半,并将拥塞窗口的大小减小为1,然后重新开始执行满启动算法。
TCP通信开始时并没有设置慢启动阀值,在重发数据时将慢启动阀值设置为当前拥塞窗口的一半大小
慢启动
最初的时候会将拥塞窗口的大小设置为一个MSS的大小,只要网络没有出现拥塞(没有发生重传),每当收到一个确认包时会将拥塞窗口的大小逐渐增大(每次增加一个MSS大小),一旦出现拥塞(发生重传),拥塞窗口就减小一些。
慢开始是指一开始向网络中注入的报文段少,并不是指拥塞窗口增长速度慢
拥塞避免
当拥塞窗口增大到慢启动阀值时,只允许以一定比例放大拥塞窗口:1个数据段的字节数 / 拥塞窗口字节数 * 1个数据段字节数。
拥塞避免并非指完全能够避免拥塞,而是指在拥塞避免阶段将拥塞窗口控制位按线性规律增长。是网络比较不易出现拥塞
快重传
当某个分组丢失时,发送方就会认为网络发生了拥塞,其实可能此时并未发生拥塞,而发送方却将拥塞窗口和慢启动阀值变小了,快重传的出现解决了这个问题。
快重传即指是发送方尽快重传,而不是等超时重传计时器超时再重传,因此要求接收方没接受到一个分组时都要进行确认应答,而不是等自己发数据时进行捎带应答。发送方一旦收到三个连续的重复确认,就会重传该分组。
快恢复
当发送方进行快重传时,将慢启动阀值更新为当前窗口大小的一半,并将拥塞窗口大小设置为当前慢启动阀值+3个数据段的大小。
进行拥塞控制时拥塞窗口的情况如下图所示:
保活机制
TCP的连接实际上是软件层面的连接,物理层并没有连接的概念,而且物理层也并不能检测到是否有连接状态。
- 在通信双方建立连接后,不是一直在进行数据传输,没有数据交互时的连接称为半打开连接,一般短连接在发送完数据后就会关闭连接,但是长连接会一直保存着连接不断开。随着时间的积累,可能会有很多半打开的连接,这就会非常消耗端系统的资源,因此TCP引入了连接保活机制
- TCP连接在一定的时间间隔后会发送一个探测包来验证对端是否还存活,若接收到ACK包,则证明对端还存活,在超过一定次数的探测之后还是没有收到ACK包的话就会关闭该连接。
- 发送探测包会造成一定的网络流量的产生,而且该保活只能在内核层级检测连接是否存活,而连接的存活不一定代表服务可用。比如若电脑的CPU已经处于100%状态,实际上此时电脑已经无法处理响应,而保活机制仍然认为连接可用
常见面试题
TCP和UDP的区别
UDP特点:无连接;尽力而为交付数据;面向报文(应用层发来的报文在加上UDP头部之后直接发送,不进行分割);无拥塞控制;支持一对一、一对多、多对多和多对一;首部开销小,只有8字节;不可靠数据传输;时延小;实时性强。
TCP特点:面向连接;面向字节流;提供流量控制和拥塞控制;一对一;首部开销大(固定首部20字节);提供可靠数据传输。
- 有无连接
- TCP是面向连接的传输,在发送数据之间需要进行三次握手建立连接,结束发送数据时需要进行四次挥手去断开连接
- UDP在发送数据时不需要建立连接,接到应用层报文后直接发送出去,因此效率较高
- TCP是一对一的服务,UDP可以使一对一、一对多、多对一、多对多的服务
- 对系统资源的要求
- TCP首部需要20个字节,而UDP首部只需要8个字节
- UDP程序结构较简单
- 体现在报文首部,UDP的报文首部只有源端口号、目的端口号、报文长度、校验和四个字段,而
- 流量控制与拥塞控制
- TCP有对数据进行流量控制,通过滑动窗口、拥塞窗口和慢启动来实现
- TCP是面向字节流的服务,UDP是面向报文的服务
- 具体体现在:TCP会对应用层报文进行分段,每次发送的数据包不能大于一个MSS,而UDP接收到应用层报文之后只添加UDP首部,然后就会直接发送出去
- TCP保证数据的可靠性,和数据包顺序;UDP可能丢包,并不保证数据包顺序
- TCP通过编号和确认应答保证数据的可靠性传输,也可通过序号来确保数据包的顺序
TCP的三次握手与四次挥手
TCP是面向连接的协议,因此在实际通信之前会先建立连接通道,然后才开始传递实际的数据;三次握手的一个重要功能是客户端和服务器交换ISN,以便让对方知道接下来接收数据的时候如何按***组装数据
ISN是第一次握手时数据包的seq字段的值
ISN = M + F(localhost, localport, remotehost, remoteport)
M是一个计时器,每隔4毫秒加1。 F是一个Hash算法,根据源IP、目的IP、源端口、目的端口生成一个随机数值。要保证hash算法不能被外部轻易推算得出。
三次握手
第一次握手:客户端会先向服务器发送一个SYN包(SYN=1,seq=x)请求连接,此时客户端进入SYN_SEND状态
第二次握手:服务器接收到客户端发来的SYN包之后,会进行请求响应,即发送(ACK+SYN)包(ACK=1,SYN=1,seq=y,ack=x+1)请求建立连接,此时服务器进入SYN_RCVD状态
第三次握手:客户端收到服务器的连接请求后会进行确认应答,即向服务器返回一个ACK包(ACK=1,ack=y+1),发送完毕之后,客户端进入ESTABLISHED状态,当服务器接收到该ACK包后也进入ESTABLISHED状态
在三次握手之后,连接正式建立,此时开始传送真正的数据
第三次握手时发送的ACK包丢失的情况
当发送的ACK包在途中丢失时,服务器过一段时间会重新发送ACK+SYN包,若重发一定次数之后还是未接收到ACK包,就会关闭此次连接
四次挥手
在数据交换完成之后,任意一方都可以请求断开连接
第一次挥手:主动断开连接的一方会向被动断开连接的一方发送一个FIN包(FIN=1,seq=x)请求断开连接,请求断开连接的一方进入FIN_WAIT_1状态
第二次挥手:接收到FIN包的一方会返回一个ACK包(ACK=1,ack=x+1)进行响应,接收到FIN包的一方进入CLOSE_WAIT状态,客户端接收到该ACK包后,进入FIN_WAIT_2状态
第三次挥手:在返回ACK包后,当缓冲区的数据处理完毕之后,会再发送一个FIN包(ACK=1,FIN=1,ack=x+1,seq=y)去请求断开连接,被动关闭连接的一方进入LAST_ACK状态,等待主动断开连接一方的ACK包
第四次挥手:主动断开连接的一方在收到对方发来的FIN包后,会再返回一个ACK包(ACK=1,ack=y+1)作为应答,发送ACK包后,主动断开连接的一方进入CLOSED状态,被动断开连接的一方在接收到该ACK包后也进入CLOSED状态。
四次挥手之后主动方要等2MSL后才会到CLOSED状态的原因
在第四次挥手发送ACK包之后,主动断开连接的一方会等待2MSL后才会变为CLOSED状态,因为最后一次发送的ACK包有可能会在途中丢失,此时被动断开连接的一方就会重新发送FIN包到主动断开连接的一方
三次握手四次挥手的原因
三次握手而不是两次握手的原因:若只有两次握手的话,在服务器将SYN+ACK包返回之后而没有接收到客户端返回的ACK时,就会认为连接已经建立,发送的数据客户端不会认可接收,就会导致服务器重复发送数据而客户端接收不到
四次挥手的原因:被动断开连接的一方有可能数据还没有处理完,因此他会先发送一个ACK包作为相应,表示自己接收到断开连接的请求了,然后再数据处理完毕之后再发送FIN包去断开连接
TCP的拥堵处理
首先,TCP在连接时服务器和客户端就会有一个协商处理的过程,约定好双方能够处理的最大数据时多少,之后发送的数据量不会大于此窗口大小,称之为窗口控制。
TCP在建立连接时会以一种慢启动的方式去建立连接,慢启动的基本思想是:当TCP开始在一个网络中传输数据或发现丢失并开始重发时 ,首先慢慢的对网络实际容量进行试探,避免由于发送过量数据而导致网络阻塞。当第一次发送数据时拥塞窗口的大小为一个MSS,意味着最多只能发送一个MSS大小的数据,在每接收到一个确认应答时,拥塞窗口的大小就会增大一个MSS。
因为拥塞窗口的不断增大,还有可能会导致网络拥堵情况的发生,因此引入了慢启动阀值的概念,即在重发数据包时,会第一次将慢启动阀值设置为当前拥塞窗口的一半大小,在最初的时候是没有设置慢启动阀值的。
TCP和UDP分别对应的常见应用层协议
TCP对应的协议:
- FTP:定义了文件传输协议,使用21端口。
- Telnet:一种用于远程登陆的端口,使用23端口,用户可以以自己的身份远程连接到计算机上,可提供基于DOS模式下的通信服务。
- SMTP:邮件传送协议,用于发送邮件。服务器开放的是25号端口。
- POP3:它是和SMTP对应,POP3用于接收邮件。POP3协议所用的是110端口。
- HTTP:是从Web服务器传输超文本到本地浏览器的传送协议。
UDP对应的协议:
- DNS:用于域名解析服务,将域名地址转换为IP地址。DNS用的是53号端口。
- SNMP:简单网络管理协议,使用161号端口,是用来管理网络设备的。由于网络设备很多,无连接的服务就体现出其优势。
- TFTP(Trival File Tran敏感词er Protocal),简单文件传输协议,该协议在熟知端口69上使用UDP服务。