三次握手四次挥手面试题(tcp三次握手四次挥手面试题)

我们可以看到首先主机A发送一个SYN报文打算建立连接， SYN=1 ACK=0 seq=x然后主机B收到请求报文后，返回确认报文SYN=1 ACK=1 seq=y ack=x+1SYN=1代表这条不是普通报文，是一个请求或者响应报文ACK=0 请求　ACK=1响应然后主机A对报文进行确认SYN=0 ACK=1 seq=x+1 ack=y+1之前的主机A发送的SYN报文消耗一个序号　所以这里的seq=x+1为了防止已经失效的报文突然又传送到主机B这里假设一种情况，主机A发送了一个SYN报文，然后这个报文因为网络阻塞等原因，延误到报文超时失效才达到主机B。主机B误认为是A的另一次请求，则同意并返回确认报文。然而主机A因为没有发送请求报文，而不理会这个确认报文。也不向主机B发送数据，主机B一直等待，资源浪费。如果是三次握手，则刚刚主机B发生的确认报文，主机A不会发送确认。主机B没接受确认也不会建立这次连接了。我们首先看到主机A发送一个FIN报文请求释放连接FIN=1 seq=uFIN报文消耗一个序号，这里seq=u是上一次传输数据的最后一个字节的序号+1主机B收到FIN报文，返回确认报文ACK=1 ack=u+1 seq=vv也是主机B已经传送过数据最后一个字节序号+1主机B通知上层应用，A到B的连接释放，此时处于半连接状态B可能还要向A传送数据...B不再向A发送数据，上层应用通知TCP释放连接B发起一个FIN报文FIN=1 ACK=1 ack=u+1 seq=v对上一次的一端释放的确认，同时发送这一方的释放，上一次发送的ACK报文不消耗序号 seq=vA收到报文后，发送确认报文ACK=1 ack=v+1 seq=u+1FIN报文消耗一个序号seq=u+1等待超时2MSL在等待过程中若A没有再收到B的FIN报文，则代表A的确认报文没有丢失，释放连接。若有，A再重传确认报文到B等待超时。65535-20-20=65495因为IP数据报最大长度65535 TCP首部20字节 IP首部20字节，剩下的就是数据部分。数据的字节长度超过TCP报文段中的序号字段可能编出的最大序号，通过循环使用序号，仍能用TCP来传送。完全可能。设想A连续发送两个报文段：（SEQ＝92，DATA共8个字节）和（SEQ＝100，DATA共20字节），均正确到达B。B连续发送两个确认：（ACK＝100）和（ACK＝120）。但前者在传送时丢失了。于是A超时重传（SEQ＝92，DATA共8字节），而B再次收到该报文段后，发送（ACK＝100）。这样，在这个报文段之前发送的就是（ACK＝120）。现在假设如果我们在客户端（客户端）浏览器中输入http://www.baidu.com,而 baidu.com 为要访问的服务器（服务器），下面详细分析客户端为了访问服务器而执行的一系列关于协议的操作：1）客户端浏览器通过DNS解析到www.baidu.com的IP地址220.181.27.48，通过这个IP地址找到客户端到服务器的路径。客户端浏览器发起一个HTTP会话到220.161.27.48，然后通过TCP进行封装数据包，输入到网络层。2）在客户端的传输层，把HTTP会话请求分成报文段，添加源和目的端口，如服务器使用80端口监听客户端的请求，客户端由系统随机选择一个端口如5000，与服务器进行交换，服务器把相应的请求返回给客户端的5000端口。然后使用IP层的IP地址查找目的端。3）达到IP层之后，主要做的是通过查找路由表确定如何到达服务器，期间可能经过多个路由器，这些都是由路由器来完成的工作，通过查找路由表决定通过那个路径到达服务器。4）客户端的链路层，包通过链路层发送到路由器，通过邻居协议查找给定IP地址的MAC地址，然后发送ARP请求查找目的地址，如果得到回应后就可以使用ARP的请求应答交换IP数据包，然后再根据路由表的路径再次交换，直到交换到目的地址的路由器之后，最终到达目的网络上的一个主机。这时双方就传输成功了。客户端发送IP数据包到达服务器的地址。IP地址由网络号（包括子网号）和主机号组成，网络地址的主机号为全0，网络地址代表着整个网络。比如：128.0.0.0广播地址与网络地址的主机号正好相反，广播地址中，主机号为全1。当向某个网络的广播地址发送消息时，该网络内的所有主机都能收到该广播消息。A类地址以0开头，第一个字节作为网络号，地址范围为：0.0.0.0~127.255.255.255；B类地址以10开头，前两个字节作为网络号，地址范围是：128.0.0.0~191.255.255.255;C类地址以110开头，前三个字节作为网络号，地址范围是：192.0.0.0~223.255.255.255。D类地址以1110开头，地址范围是224.0.0.0~239.255.255.255，D类地址作为组播地址（一对多的通信）；E类地址以1111开头，地址范围是240.0.0.0~255.255.255.255，E类地址为保留地址，供以后使用。注：只有A,B,C有网络号和主机号之分，D类地址和E类地址没有划分网络号和主机号。A、B、C类私有地址私有地址(private address)也叫专用地址，它们不会在全球使用，只具有本地意义。A类私有地址：10.0.0.0/8，范围是：10.0.0.0~10.255.255.255B类私有地址：172.16.0.0/12，范围是：172.16.0.0~172.31.255.255 C类私有地址：192.168.0.0/16，范围是：192.168.0.0~192.168.255.255

tcp：提供面向连接的服务，数据传输前先建立连接，传输完毕后释放连接，提供可靠连接； udp：发送数据前不需要先建立连接，发送后也不需要释放连接，减少开销和延迟，但不保证可靠交付。 tcp建立连接的时候需要三次握手，释放连接需要4次挥手。

为什么要三次握手 三次握手的目的是建立可靠的通信信道，说到通讯，简单来说就是数据的发送与接收，而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。第一次握手：Client 什么都不能确认；Server 确认了对方发送正常，自己接收正常第二次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：对方发送正常，自己接收正常第三次握手：Client 确认了：自己发送、接收正常，对方发送、接收正常；Server 确认了：自己发送、接收正常，对方发送、接收正常所以三次握手就能确认双发收发功能都正常，缺一不可。 第四次握手：任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
只知道三次握手，A向B发送信息，B会向A返回一个收到确认的消息，A还会对这个确认消息发送一次再确认，所以一个消息要经过三次的消息交互才算发送完成，这就是三次握手

我有一个朋友，小泷，他与我倾诉：他在咖啡厅与朋友闲谈，遇到了一个让时间彷佛静止的女孩。他描述，那一刻，他的心彻底被抓住了，脑中轰然，眼睛无法再从她身上移开。 而女孩，也时不时向她望来，那是一双如秋水般清澈的明眸。小泷说，他非常非常想想把握，这一次心动。然而，自始自终，他没能迈出那一步，他不知道该怎么办。小泷的困境，是每个男孩的困境。我告诉他，如果你懂得TCP协议，就会把握一段感情了。TCP(Transmission control protocal)，传输控制协议，既是机器与机器间传输信息的基础协议，也是人与人联立联系的准则。如何体面地认识她？ 如果读懂她是否对你有好感？ 如何给予她安全感？ 如何离别时要到她的手机号？ TCP协议，把一切写得清清楚楚。我对小泷说：一个女孩，不管她性格有多高冷，永远是欣然接受你的好感的。你要做的，也必须要做的，是：我告诉小泷，我也曾经在机场遇到过让我瞬间心动的女孩，我所做的，只是很自然走上去，告诉她："你好像也坐这趟飞机？ 航班号是KN5855没错吧"这对男孩是很简单的事情，因为你们出现的地点，就是共鸣。你关于这个地方，一定有一些具体信息可以分享。所以，小泷，你应走上去说：你也常来这家咖啡厅吧，他们家的焦糖玛奇朵非常棒。这样的谈话，对女孩是提供安全感的：你是一个拥有共同话题，并且会提供实质性价值的男士，而不是随随便便乱勾搭的人。 共鸣的力量是非常强大的，没有女孩会拒绝回应的，即使长相略显寒酸。说回TCP协议，它是这样规定的：(SYN是synchronization同步的简称，seq为sequcence序号的缩写。)这时，客户端的状态更改为SYN-SENT（synchronization_sent同步已发送）状态。也就是说，小泷，你耐心待着女孩回应就是了。这就是“第一次握手”。有了你提供的同步请求SYN=1和具体信息seq=x。女孩会根据这个信息做出响应。女孩这时的状态从LISTEN变为SYNC_RCVD（synchronization_recieved同步已收到）。我在机场遇到的女孩是这样回答我的：嗯嗯，我也坐这趟航班，不过没看到你。你是来深圳出差么？这样回答，是人之常情。你一定可以得到亲切友善的回应。TCP协议中是这样规定的：（ACK是acknowledgement确认的简称，小写的ack是确认编号)所以，女孩一定会认同你，并根据刚刚的信息点延展，而且会提供一个新的信息点。女孩对你不反感，但她也需要确认你是不是真对她有好感。假如我真的只是觉得航班数字很吉利呢？假如你小泷真是就喜欢喝焦糖玛奇朵呢？ 她无法确认男生是不是想和她交流，所以一定提出新话题。 而且，抛出新话题才会让彼此显得不尴尬。女孩几乎一定会这样回应：所以小泷，你心动女孩几乎一定会类似的回应：嗯嗯，我喜欢榛仁玛奇朵。我住这附近，你呢？你收到这样友好的回应，心中一定，知道，以后至少可以建立起初步的友谊了。 这时，你的状态更改为ESTABLISHED。(建立连接)虽然对于你，这段男女间青涩的友谊已经建立起了。但女孩，她还在等待你的回应 —— 她也在担忧你只是随意的询问吧。快赶紧安抚这一个善良美好的女孩吧！比如我会回答：嗯是的，有几个客户在深圳需要谈。我坐的商务舱所以没看到你吧。所以，小泷，你需要对她的新话题有所回应，并且不要丢掉自己的话题。这样两个话题都可以聊下去。在TCP协议中这样规定：这对女孩是非常重要的，你对她的话也表示认同，并且也能接住她的话题，同时自己的话题也没有丢掉。——是个能照顾她感受，也坚持自我的人。这时，女孩的状态成为了ESTABLISHED。你们双方都成为了ESTABLISHED，接下来，你们就可以畅通无阻地交流了。男孩会想，我怎么表现得靠谱？ TCP给出了答案，共鸣 + 具体话题。女孩心中会想： 他对我感兴趣吗？他是聊得来的人吗？ 如何进行“废物测试”？TCP给出了答案：共鸣 + 同意 + 对方话题的延展 + 新具体话题。男孩心中会想，怎么给她留下有主见高情商的好印象？TCP给出了答案： 同意 + 对方话题的延展 + 继续自己话题。仔细想想，这样的方式，让双方既不显尴尬，又体面舒适，又节约了两个人的时间与精力。时间总是短暂的，你们相谈甚欢，到了离别的时候。只有一个体面的离别，才意味着未来依然可以关系持续升温。放心，TCP协议已经为你规划好了。作为主动方的男生，需要首先表示分别，千万不要拖泥带水等到女生提出，这样才能为这段邂逅留下回味与不舍。你需要这时候，是要手机号/微信号的最佳时机。TCP协议是这样规定的：（FIN的意思是finis终结的意思）你已经请求结束了，安静地等待就好。 主动而沉默，给予女生足够的空间，这是最体面的分别方式。这时你的状态是FIN-WAIT-1（终止待待1）热情的聊天突然嘎然而止。女生心中会有些小失落，这时你要微信的请求，她几乎一定会同意。这时女生会找纸张，把自己的手机号或微信号写给你。并跟你说一些其它话。比如她说：嗯是的，等我写给你。你看外面好像快下雨了。TCP协议是这样规定的：因为是你提出离开，女孩还意犹未尽。一方面会同意离开，一方面会延展你的话题。为了确认你确实想离开了，她一般会说一个新话题，比如下雨了。女孩从接到你的离开请求，到回应你这一句的时候，她处于CLOSE_WAIT状态，她会开始进行心理建设，适应你离开时的空洞感。当然，成年人的表达方式，总是隐晦而体面的。只是一句淡淡的“天快下雨了”。而你听到她说这些，只是静静不说话。你进入FIN-WAIT-2状态。你在等着她的手机号，说话可能她突然不写了呢？忍住，别回应。当女孩低头写好手机号，她也做好了离开的心理建设，知道这一次邂逅到此为止了。这时，她说：快回去吧，我写给你啦。 不知道为什么和你呆一起挺愉快的。看，TCP协议影响着你们的一个个行为模式。你不回应，她会换个话题，她会开始猜，她会开始等，她会开始留恋。TCP协议是这样规定的：说出这句话的女孩，进入了LAST_ACK(最终动作)状态——主动权在你，她等着你。你听到女孩再次说话，你会不舍，你等着些什么。你进入TIME_WAIT阶段。知道她要离开了，你的心会突然一痛。但离开已成必然，体面地对她说最后的话吧！TCP协议是这样规定的：听到你说完这句话，女孩把车门关上，车缓缓启动了。女孩进入状态CLOSED（关闭连接）。提出离别的你，却久久站在原地。等了2MSL(两次交谈响应时间那么长)，你好希望车突然停下，女孩从车上下来。但一切没有发生。美好的邂逅结束了。你进入CLOSED状态。小泷，你知道吗？懂得TCP协议，也就懂得了如何去抓住属于撩拨你心弦的那个女孩。也许，这才是邂逅时应该的画面：离别时，你们会这样不舍离别：然后，她离开了。你凝望着她，一再回头，直到消失在视线外。每天，有万亿亿次TCP连接，都在为你重演着这一个画面。勇敢一点，不用担心被拒绝，万亿亿次TCP连接都成功了，你怎么会失败呢？因为TCP是网络通讯的规则，也是人类间默契的交流规则。不动声色，内心早已暗流汹涌。却只是对你说。“好巧，我也是这趟航班”几条规则，有助于你记住这一切：

TCP是面向连接的协议。传输连接是用来传送TCP报文的，TCP连接传输的三个阶段分别为：连接建立、数据传送和连接释放。TCP连接的建立采用客户服务器模式。主动发起连接建立的应用进程叫做客户，而被动等待连接建立的应用进程叫做服务器。TCP建立连接的过程叫做握手，握手需要在客户和服务器之间交换三个TCP报文段，三次握手的过程如下图所示。(2)第二次握手：服务器收到 SYN报文段后，如同意连接，则服务器会为该TCP连接分配缓存和变量，并向客户端返回确认报文段，在确认报文段中同步位 SYN = 1 和 确认位 ACK= 1，确认号 ack = x + 1，同时也为自己选择一个初始序号 seq = y。这时TCP服务器进程进入同步收到（SYN-RCVD）状态。(3)第三次握手：客户进程在收到服务器进程的确认报文后，客户端为该TCP连接分配缓存和变量，并向服务器端返回一个报文段，这个报文段是对服务器确认报文段进行确认，该报文段中 ACK = 1，确认号 seq = y + 1，而自己序号为 x + 1（即第二次握手服务器确认报文段的确认号）。客户端在发送ACK报文段后进入已建立连接（ESTABLISHED）状态，这时TCP连接已经建立。当服务器收到客户端的确认后，也进入ESTABLISHED状态。这样选择序号的目的是为了防止由于网络路由TCP报文段可能存在延迟抵达与排序混乱的问题，从而而导致某个连接的一方对它作错误的解释。下图表示了建立连接使用固定的序号存在的问题：由于一个TCP连接是被一对端点所表示的，其中包括2个IP地址和2个端口号构成的4元组，因此即便是同一个连接也会出现不同的实例，如果连接由于某个报文段长时间延迟而关闭，然后又以相同的4元组被重新打开，那么可以相信延迟的报文段又会被视为有效据重新进入新连接的数据流中，这就会导致数据乱序问题。为了避免上述的问题，避免连接实例间的序号重叠可以将风险降至最低。如前文所述，一个TCP报文段只有同时具备连接的4元组与当前活动窗口的序列号，才会在通信过程中被对方认为是正确的。然而，这也反应了TCP连接的脆弱性：如果选择合适的序列号、IP地址和端口号，那么任何人都能伪造一个TCP报文段，从而打断TCP的正常连接。所以使用初始化序号的方式（通常随机生成序号）使得序列号变得难猜，或者使用加密来避免利用这种缺点被攻击。所以，可以明白在建立TCP连接时，客户端和服务器端初始化序列号，就避免了上述的问题。前面说过，TCP序号占32位，范围是0~232- 1，并且可以重用。假如 第一次握手可以携带数据的话，如果有人使用伪TCP报文段恶意攻击服务器，那么每次都在第一次握手中的SYN报文中携带大量的数据，因为它不会理会服务器的发送和接收能力是否正常，不断地给服务器重复发送这样携带大量数据的SYN报文，这会导致服务器需要花费大量的时间和内存来接收这些报文数据，这会将导致服务器连接资源和内存消耗殆尽。所以，之所以第一次握手不能携带数据，其中的一个原因就是避免让服务器受到攻击。而对于第三次握手，此时客户端已经建立了连接，通过前两次已经知道了服务器的接收正常，并且也知道了服务器的接收能力是多少，所以可以携带数据。根据前面描述，在第一次握手，客户端向服务发送建立连接请求，第二次握手，服务器同意建立连接，并向客户端返回一个确认报文，至此客户端已经知道了服务器同意建立连接，为什么客户端还需要对服务器的允许连接报文段进行确认？第三个ACK报文段的目的简单来说主要是为了实现可靠数据传输。三次握手的目的不仅在于让通信双方了解一个连接正在建立，还在于利用数据包的选项来承载特殊的信息，交换初始序列号（Initial Sequence，ISN）。为了实现可靠传输，TCP协议通信双方，都必须维护一个序列号，以标识发送出去的数据报中，哪些是已经被对方收到的。三次握手的过程是通信双方想要告知序列号起始值，并确认已经收到序列号的必经过程。如上图，在两次握手过程中，通信双方都随机选择了自己的初始段序号，并且第二次握手的时候客户端收到了自己的确认序号，确认了自己的序列号，而服务器端还没有确认自己的序列号，没有收到确认序号， 如果这时候两次握手下就进行数据传递， 序号没有同步，数据就会乱序。即如果只是两次握手，最多只有客户端的起始序列号能被确认，而服务器断的序列号则得不到确认。在三次握手的过程中，服务器为了响应一个受到的SYN报文段，会分配并初始化连接变量和缓存，然后服务器发送一个SYNACK报文段进行响应，并等待客户端的ACK报文段。如果客户不发送ACK来完成该三次握手的第三步，最终（通常在一分多钟之后）服务器将终止该半开连接并回收资源。这种TCP连接管理协议的特性就会有这样一个漏洞，攻击者发送大量的TCP SYN报文段，而不完成第三次握手的步骤。随着这种SYN报文段的不断到来，服务器不断为这些半开连接分配资源，从而导致服务器连接资源被消耗殆尽。这种攻击就是SYN泛供攻击。为了应对这种攻击，现在有一种有效的防御系统，称为SYN cookie。SYN cookie的工作方式如下：连接释放的四次挥手过程如下图所示：(2)第二次挥手：服务器收到连接释放报文段后即发出确认，确认为ACK = 1，确认号为ack = u + 1，序号seq = v（其值是服务器前面已传送过的数据最后一个字节的序号加1），然后服务器就进入了关闭等待（CLOSE-WAIT）状态。(3)第三次挥手：如果此时服务器没有数据要发送了，此时服务器向客户端发出连接释放报文段，其FIN = 1，假设器序号为seq = w（在半关闭状态下服务器可能又发送了一些数据），服务器必须重复上次以发送的确认号ack = u + 1（因为客户端没有向服务器发送过数据，所以确认号和上次一致）。这时，服务器进入最后确认（LAST-ACK）状态，等待客户端的确认。(4)第四次挥手：客户端在收到服务器端发出的连接释放报文段后，必须对此发出确认，在确认报文段中将ACK置位1，确认号ack = w + 1，而自己的序号为seq = u + 1。之后客户端进入时间等待（TIME-WAIT）状态。在经过时间等待计时器设置的时间2MSL后，客户端才进入关闭（CLOSE）状态这是为了保证客户端发送的最后一个ACK报文段能够到达服务器端。客户端发送的ACK报文段可能丢失，因而使服务器收不到对自己已发送的释放连接报文段的确认。服务器会重传连接释放报文段，重新启动2MSL计时器，最终，客户端和服务器端都能进入CLOSE状态。在建立连接时，服务器端处于LISTEN状态时，当收到SYN报文段的建立连接请求后，它可以把ACK报文段和SYN报文段（ACK报文段起确认作用，即确认客户端的连接建立请求；SYN报文段起同步作用）放在一起发送，所以在连接建立时四次握手（即第二次握手时，服务器的ACK报文段和SYN报文段分开发送）可以合并为三次握手。而在释放连接时需要四次是因为TCP连接的半关闭造成的。由于TCP是全双工的（即数据可在两个方向上同时传递），因此，每个方向都必须要单独进行关闭，这个单方向的关闭就叫半关闭。在关闭连接时，当服务器收到客户端的FIN报文通知时，它仅仅表示客户端没有数据发送服务器了；但服务器未必将所有的数据都全部发送给了客户端，所以服务器端未必马上也要关闭连接，也即服务器端可能还需要发送一些数据给客户端之后，再发送FIN报文给客户端来表示现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的，这也是为什么释放连接时需要交换四次报文了。