linux怎么查看本机内存大小
247
2022-11-06
TCP和UDP协议(TCP链接;常见TCP/UDP端口号)
TCP协议
源端口号(16) | 目标端口号(16) |
---|---|
UDP长度(16) | UDP校验和(16) |
UDP长度:用来指出UDP的总长度,为首部加上数据。 校验和:用来完成对UDP数据的差错检验,它是UDP协议提供的唯一可靠机制。 常见TCP/UDP端口号 TCP
端口 | 协议 | 说明 |
---|---|---|
21 | FTP | 文件传输协议,FTP服务器所开放的控制端口 |
22 | SSH | 安全Shell服务 |
23 | TELNET | 用于 远程登陆,可以远程控制管理目标计算机 |
25 | SMTP | 简单邮件传输协议,SMTP服务器开放的端口,用于发送邮件 |
53 | DNS | 域名系统,建立连接,区域传送 |
80 | HTTP | 用于万维网服务的超文本传输协议 |
110 | POP3 | 用于邮件的接受 |
443 | HTTPS | 安全超文本传输协议,用SSL/TLS对数据进行加密和解密,HTTP进行传输 |
UDP
端口 | 协议 | 说明 |
---|---|---|
53 | DNS | 域名系统,DNS解析 |
69 | TFTP | 简单文件传输协议 |
111 | RPC | 远程过程调用 |
123 | NTP | 网络时间协议 |
161 | SNMP | 简单网络管理协议 |
为什么需要三次握手,而不是两次?答: 防止已过期的连接请求报文突然又传送到服务器,因而产生错误和资源浪费。在双方两次握手即可建立连接的情况下,假设客户端发送 A 报文段请求建立连接,由于网络原因造成 A 暂时无法到达服务器,服务器接收不到请求报文段就不会返回确认报文段。客户端在长时间得不到应答的情况下重新发送请求报文段 B,这次 B 顺利到达服务器,服务器随即返回确认报文并进入 ESTABLISHED 状态,客户端在收到 确认报文后也进入 ESTABLISHED 状态,双方建立连接并传输数据,之后正常断开连接。此时姗姗来迟的 A 报文段才到达服务器,服务器随即返回确认报文并进入 ESTABLISHED 状态,但是已经进入 CLOSED 状态的客户端无法再接受确认报文段,更无法进入 ESTABLISHED 状态,这将导致服务器长时间单方面等待,造成资源浪费。2.三次握手才能让双方均确认自己和对方的发送和接收能力都正常。第一次握手:客户端只是发送处请求报文段,什么都无法确认,而服务器可以确认自己的接收能力和对方的发送能力正常;第二次握手:客户端可以确认自己发送能力和接收能力正常,对方发送能力和接收能力正常;第三次握手:服务器可以确认自己发送能力和接收能力正常,对方发送能力和接收能力正常;可见三次握手才能让双方都确认自己和对方的发送和接收能力全部正常,这样就可以愉快地进行通信了。3.告知对方自己的初始序号值,并确认收到对方的初始序号值。TCP 实现了可靠的数据传输,原因之一就是 TCP 报文段中维护了序号字段和确认序号字段,通过这两个字段双方都可以知道在自己发出的数据中,哪些是已经被对方确认接收的。这两个字段的值会在初始序号值得基础递增,如果是两次握手,只有发起方的初始序号可以得到确认,而另一方的初始序号则得不到确认。 为什么要三次握手,而不是四次?答: 第一次握手:服务端确认“自己收、客户端发”报文功能正常。 第二次握手:客户端确认“自己发、自己收、服务端收、客户端发”报文功能正常,客户端认为连接已建立。 第三次握手:服务端确认“自己发、客户端收”报文功能正常,此时双方均建立连接,可以正常通信。 为什么连接的时候是三次握手,关闭的时候却是四次握手?答:服务器在收到客户端的 FIN 报文段后,可能还有一些数据要传输,所以不能马上关闭连接,但是会做出应答,返回 ACK 报文段.接下来可能会继续发送数据,在数据发送完后,服务器会向客户单发送 FIN 报文,表示数据已经发送完毕,请求关闭连接。服务器的ACK和FIN一般都会分开发送,从而导致多了一次,因此一共需要四次挥手。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~