当前位置:首页 » 网络连接 » 计算机网络中三次握手用于
扩展阅读

计算机网络中三次握手用于

发布时间: 2024-12-04 07:01:20

⑴ TCP连接建立过程中为什么需要“三次握手”

传输控制协议 TCP)是一种面向连接的、可靠的、基于字节流的运输层(Transport layer)通信协议。是专门为了在不可靠的互联网络上提供一个可靠的端到端字节流而设计的。互联网络与单个网络不同,因为互联网络的不同部分可能有着截然不同的拓扑、带宽、延迟、分组大小和其他参数。TCP的设计目标是能够动态的适应互联网络的这些特性,而且当面对多种失败的时候仍然能够健壮。 每一次TCP连接都需要三个阶段:连接建立、数据传送和连接释放。三次握手就发生在连接建立阶段。 在谢希仁着《计算机网络》第四版中讲三次握手的目的是 为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。在另一部经典的《计算机网络》一书中讲三次握手的目的是为了解决 网络中存在延迟的重复分组的问题。 这两种不用的表述其实阐明的是同一个问题。 谢希仁版《计算机网络》中的例子是这样的,已失效的连接请求报文段的产生在这样一种情况下:client发出的第一个连接请求报文段并没有丢失,而是在某个网络结点长时间的滞留了,以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后,就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段,同意建立连接。假设不采用三次握手,那么只要server发出确认,新的连接就建立了。由于现在client并没有发出建立连接的请求,因此不会理睬server的确认,也不会向server发送数据。但server却以为新的运输连接已经建立,并一直等待client发来数据。这样,server的很多资源就白白浪费掉了。采用三次握手的办法可以防止上述现象发生。例如刚才那种情况,client不会向server的确认发出确认。server由于收不到确认,就知道client并没有要求建立连接。 这个例子很清晰的阐释了三次握手对于建立可靠连接的意义。 在Google Groups的 TopLanguage 中看到一帖讨论TCP三次握手觉得很有意思。贴主提出 的问题,在众多回复中,有一条回复写道:这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了. 。这可视为对三次握手目的的另一种解答思路。

⑵ 三次握手机制用于解决什么

用于解决网络中出现重复请求报文的问题。

第一次:首先A发送一个(SYN)到B,意思是A要和B建立连接进行通信,如果是只有一次握手,这样肯定是不行的,A压根都不知道B是不是收到了这个请求。

第二次:B收到A要建立连接的请求之后,发送一个确认(SYN+ACK)给A,意思是收到A的消息了,B这里也是通的,表示可以建立连接。如果只有两次通信,这时候B不确定A是否收到了确认消息,有可能这个确认消息由于某些原因丢了。

第三次:A如果收到了B的确认消息之后,再发出一个确认(ACK)消息,意思是告诉B,这边是通的,然后A和B就可以建立连接相互通信了。

(2)计算机网络中三次握手用于扩展阅读:

注意事项:

刚接触网络编程时,感觉网络连接的建立、网络数据的收发、网络连接的断开这些操作仅仅是调用几个socket AIP就可以搞定的事情,跟网络中讲述的TCP三次握手等内容完全扯不上关系。

listen函数:内核为任何一个给定的套接字维护两个队列 1.未完成连接状态(客户端发送的第一个SYN已经到服务器,服务器等待TCP三次握手完成,这些套接字处于SYN_RCVD状态)。

⑶ 一文搞定 UDP 和 TCP 高频面试题!

在求职面试中,UDP和TCP是常被问到的计算机网络概念。无论春招秋招,面试官几乎都会涉及这些问题,尤其在作者参加的50场面试中,几乎每轮都有涉及。了解这些问题不仅能提升面试自信,还能给面试官留下深刻印象。本文将总结常见的面试问题,帮助你应对相关知识点。



  • UDP和TCP特点:UDP是无连接、尽力而为、不保证顺序,支持多对多通信,而TCP是面向连接、可靠传输、有流量控制和拥塞控制,一对一通信。

  • 首部格式:UDP只有8字节,包括源端口、目的端口等;TCP首部复杂,包含序号、确认号、窗口值等控制位,用于保证数据完整性和可靠性。

  • 三次握手:TCP建立连接,防止连接请求失效,确认双方接收和发送能力正常。

  • 四次挥手:关闭连接,确保数据传输完成,服务端等待所有数据发送完再发送FIN,客户端等待服务器确认关闭。

  • 短连接与长连接:短连接是一次操作就断开,长连接可多次数据交换,管理复杂但可复用连接。

  • 粘包和拆包:TCP基于字节流,可能导致数据包重组,需要通过应用层协议处理。

  • 可靠传输与流量控制:TCP通过超时重传和滑动窗口机制确保数据完整,流量控制防止接收方过载。


掌握这些核心知识点,面试时就能从容应对,展现你的专业知识。最后,不要忘了实践和复习,让知识真正运用到实际中。

⑷ 计算机网络经典20问

本文目录

计算机网络体系大致分为三种,OSI七层模型、TCP/IP四层模型和五层模型。一般面试的时候考察比较多的是五层模型。

TCP/IP五层模型:应用层、传输层、网络层、数据链路层、物理层。

假设发送端为客户端,接收端为服务端。开始时客户端和服务端的状态都是 CLOSED 。

第三次握手主要为了 防止已失效的连接请求报文段 突然又传输到了服务端,导致产生问题。

因为当Server端收到Client端的 SYN 连接请求报文后,可以直接发送 SYN+ACK 报文。 但是在关闭连接时,当Server端收到Client端发出的连接释放报文时,很可能并不会立即关闭SOCKET ,所以Server端先回复一个 ACK 报文,告诉Client端我收到你的连接释放报文了。只有等到Server端所有的报文都发送完了,这时Server端才能发送连接释放报文,之后两边才会真正的断开连接。故需要四次挥手。

HTTP请求由 请求行、请求头部、空行和请求体 四个部分组成。

请求报文示例

HTTP响应也由四个部分组成,分别是: 状态行、响应头、空行和响应体

响应报文示例

HTTP2.0相比HTTP1.1支持的特性:

服务端可以向证书颁发机构CA申请证书,以避免中间人攻击(防止证书被篡改)。证书包含三部分内容: 证书内容、证书签名算法和签名 ,签名是为了验证身份。

服务端把证书传输给浏览器,浏览器从证书里取公钥。证书可以证明该公钥对应本网站。

数字签名的制作过程

浏览器验证过程

首先是TCP三次握手,然后客户端发起一个HTTPS连接建立请求,客户端先发一个 Client Hello 的包,然后服务端响应 Server Hello ,接着再给客户端发送它的证书,然后双方经过密钥交换,最后使用交换的密钥加解密数据。

对称加密 :通信双方使用 相同的密钥 进行加密。特点是加密速度快,但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有 AES 和 DES 算法。

非对称加密 :它需要生成两个密钥, 公钥和私钥 。公钥是公开的,任何人都可以获得,而私钥是私人保管的。公钥负责加密,私钥负责解密;或者私钥负责加密,公钥负责解密。这种加密算法 安全性更高 ,但是 计算量相比对称加密大很多 ,加密和解密都很慢。常见的非对称算法有 RSA 和 DSA 。

⑸ 计算机网络中的“三次握手”是什么

TCP握手协议

在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接。

第一次握手:建立连接时,客户端发送syn包(syn=j)到服务器,并进入SYN_SEND状态,等待服务器确认;
SYN:同步序列编号(SynchronizeSequenceNumbers)
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;

第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

完成三次握手,客户端与服务器开始传送数据,在上述过程中,还有一些重要的概念:

未连接队列:在三次握手协议中,服务器维护一个未连接队列,该队列为每个客户端的SYN包(syn=j)开设一个条目,该条目表明服务器已收到SYN包,并向客户发出确认,正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态,当服务器收到客户的确认包时,删除该条目,服务器进入ESTABLISHED状态。
Backlog参数:表示未连接队列的最大容纳数目。

SYN-ACK重传次数服务器发送完SYN-ACK包,如果未收到客户确认包,服务器进行首次重传,等待一段时间仍未收到客户确认包,进行第二次重传,如果重传次数超过系统规定的最大重传次数,系统将该连接信息从半连接队列中删除。注意,每次重传等待的时间不一定相同。

半连接存活时间:是指半连接队列的条目存活的最长时间,也即服务从收到SYN包到确认这个报文无效的最长时间,该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。