文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
文章收录在网站:http://hardyfish.top/
什么是滑动窗口
TCP滑动窗口是TCP协议中实现流量控制和可靠传输的关键机制。
滑动窗口不仅可以防止发送端数据传输过快,以至于接收端处理不过来
- 还可以对丢失的数据包进行重传,以确保数据的可靠传输。
工作原理
在TCP连接中,每个方向上都有一个发送窗口和一个接收窗口。
- 窗口的大小是动态变化的,表示接收端目前还能接收的字节数。
当发送端发送数据时,发送的数据不能超过发送窗口的大小。
- 发送的数据被编号,放入发送窗口,并逐个发送出去。
- 每发送一个数据包,发送窗口就向右滑动一个数据包的距离。
接收端在接收到数据包后,会向发送端确认已接收到的数据包序号,并告诉发送端自己的接收窗口大小。
- 接收端的确认可以是累积的,也就是说,如果一次确认了多个数据包,那么需要通知的是最后一个接收到的数据包的序号。
发送端在收到确认后,会把确认的数据从发送窗口中移除
同时根据接收端告知的接收窗口的大小,调整自己的发送窗口大小。
然后发送窗口向右滑动,继续发送后面的数据包。
如果发送端没有收到接收端的确认,那么发送端就会重发该数据包。
- 这就是TCP协议如何保证数据的可靠传输的。
举例说明
假设你正在给一个朋友发送一封邮件。你的朋友告诉你他的邮箱只能接收5MB的数据。
- 所以你把邮件分成5个1MB的部分,每次只能发送1MB的数据。
- 你发完一部分后,你的朋友就会确认一下已经收到的部分,并告诉你他的邮箱还能接收多少数据。
- 你每次都根据他告诉你的可以接收的数据的大小,来发送下一部分的数据。这就是滑动窗口的工作原理。
讲一讲什么是TCP粘包和拆包?
TCP粘包和拆包是网络编程中常见的问题,主要是由于TCP的特性和网络环境的影响。
TCP粘包:
就是发送方发送的若干包数据到达接收方时被粘在一起,接收方看到的可能是一个大的数据包。
这主要是因为TCP是一个基于字节流的协议,没有边界。
- 另一个原因是为了提高网络的有效利用率,TCP会尽可能地将小的数据包合并到大的数据包中发送出去。
TCP拆包:
与TCP粘包相反,拆包是指发送方发送的一个大的数据包到达接收方时被拆成多个小的数据包。
这主要是因为TCP在传输数据时,如果数据包过大
- 会被分割成合适大小的小包进行发送,以适应网络的最大传输单元(
MTU
)。举个例子
假设你正在发送一个大文件,比如一个1GB的电影。
由于网络的MTU限制,你不能一次性发送整个文件,所以你需要将文件拆分成多个小的数据包进行发送,这就是TCP拆包。
- 而在接收方,可能由于网络环境等因素,接收到的数据包可能会被粘在一起,形成一个大的数据包,这就是TCP粘包。
解决这个问题的常见方法是在应用层添加消息边界
- 比如使用特殊的分隔符,或者在消息头部添加长度字段,来标识每个消息的边界。
保活计时器的作用?
TCP 有一个保活计时器(
keepalive timer
)。客户已主动与服务器建立了 TCP 连接。
- 但后来客户端的主机突然发生故障。
- 显然,服务器以后就不能再收到客户端发来的数据。
- 因此,应当有措施使服务器不要再白白等待下去。这就需要使用保活计时器了。
服务器每收到一次客户的数据,就重新设置保活计时器,时间的设置通常是两个小时。
- 若两个小时都没有收到客户端的数据,服务端就发送一个探测报文段,以后则每隔 75 秒钟发送一次。
- 若连续发送 10个 探测报文段后仍然无客户端的响应,服务端就认为客户端出了故障,接着就关闭这个连接。
UDP 如何实现可靠传输?
UDP不属于连接协议,具有资源消耗少,处理速度快的优点,所以通常音频,视频和普通数据在传送时,使用UDP较多
- 因为即使丢失少量的包,也不会对接受结果产生较大的影响。
传输层无法保证数据的可靠传输,只能通过应用层来实现了。
- 实现的方式可以参照tcp可靠性传输的方式,只是实现不在传输层,实现转移到了应用层。
最简单的方式是在应用层模仿传输层TCP的可靠性传输。
下面不考虑拥塞处理,可靠UDP的简单设计。
- 添加seq/ack机制,确保数据发送到对端
- 添加发送和接收缓冲区,主要是用户超时重传。
- 添加超时重传机制。
送端发送数据时,生成一个随机
seq=x
,然后每一片按照数据大小分配seq。数据到达接收端后接收端放入缓存,并发送一个
ack=x
的包,表示对方已经收到了数据。发送端收到了ack包后,删除缓冲区对应的数据。
- 时间到后,定时任务检查是否需要重传数据。
目前有如下开源程序利用udp实现了可靠的数据传输。
- 分别为RUDP、RTP、UDT。
什么是 HTTP 长连接?
HTTP长连接(
HTTP persistent connection
)是指在一次HTTP请求和响应完成后,保持TCP连接不关闭
- 以便后续的HTTP请求可以继续在同一个连接上发送和接收数据。
在传统的HTTP/1.0版本中,每次请求完成后,TCP连接都会被关闭,下次请求需要重新建立连接,这种方式称为短连接。
- 而在HTTP/1.1版本中,引入了持久连接的概念,也就是HTTP长连接。
HTTP长连接的主要优势在于减少了TCP连接建立和关闭的开销,提高了性能和效率。
- 相比于短连接,HTTP长连接可以避免频繁地进行握手和挥手操作,节省了网络资源和服务器端的负担。
通过HTTP长连接,客户端和服务器之间可以在同一个TCP连接上发送多个HTTP请求和接收多个HTTP响应
而不需要每次都重新建立连接。
这样可以减少延迟,提高响应速度,特别适用于同时请求多个资源,或在一个页面中含有多个嵌入资源的情况。
需要注意的是,HTTP长连接并不会一直保持不断开,它有一个超时时间。
如果在一段时间内没有新的请求发送,服务器可能会主动关闭连接,或者客户端也可以选择关闭连接。
- 同时,服务器端和客户端都可以通过
Connection
头字段中的选项来控制是否启用长连接。HTTP长连接是一种通过保持
TCP
连接的方式,在一次连接上进行多次请求和响应的机制,以提高性能和效率。
HTTP 常见方法有哪些?
标签:发送,HTTP,请求,真题,TCP,计算机网络,面试,数据包,连接 From: https://blog.csdn.net/qq_35508033/article/details/141555472HTTP(超文本传输协议)常见的请求方法有以下几种:
GET:用于请求服务器返回指定资源的数据。
- 通常用于获取或查看资源,GET请求不应该对服务器的状态产生任何影响。
POST:用于向服务器提交数据,请求服务器处理请求中的数据。
- 通常用于提交表单数据、上传文件或者执行某些会修改服务器状态的操作。
PUT:用于向服务器上传或更新资源,请求服务器存储请求中的数据。
- 通常用于更新或上传文件等操作。
DELETE:用于请求服务器删除指定的资源。
- 通常用于删除服务器上的文件或者数据。
HEAD:类似于GET请求,但不返回具体的资源数据,而只返回资源的元信息(例如响应头部)
- 用于获取资源的元信息而不获取实际的资源内容。
OPTIONS:查询服务器支持的HTTP方法。
- 客户端可以使用OPTIONS方法来获取服务器所支持的HTTP方法列表。
TRACE:用于向服务器发送一个请求,服务器将此请求返回给客户端,用于追踪请求的路径。
这些HTTP请求方法在实际的应用中常常被用于不同的操作场景和业务需求中
- 比如GET用于获取数据,POST用于提交数据等。
开发者可以根据实际需求选择合适的HTTP请求方法来进行数据交互