tcp四次挥手

HTTP 是什么？ HTTP 解决了什么？为什么出现？ 假设只有 TCP，没有应用层： 客户端、服务器开发人员制定接口需要定好发送、接收数据的格式。比如服务器执行成功返回 1，执行失败返回 0 等。但是其他服务器的接口格式不一定就是这样，可能返回的执行结果是字符串。所以客户端针对每个系统的接口都需要分别写发送、解析数据的方法。 而 HTTP 就是为了解决这类问题，在应用层给客户端、服务端制定了一个规范。 ​ HTTP/1.1 是什么？跟 1.0 有什么区别？ HTTP 是基于 TCP 的协议，所以连接必须有三次握手、四次挥手。 在 HTTP/1.0 ，每次做 HTTP 请求，都需要建立、关闭 TCP 连接，即每发送 HTTP 请求就要三次握手、四次挥手。 这样比如打开一个网页，请求 HTML、CSS、JS 等就需要好几个甚至几十个 TCP 连接，所以性能低。这种每次请求就要一个 TCP 连接、返回再关闭 TCP 连接的，叫 短连接 。 而 HTTP/1.1 为了解决该问题，让多个 HTTP 请求共用一个 TCP 连接，从而减少了不必要的网络请求。 客户端在请求 HTTP header 里设置 Connection: keep-alive，并且服务器返回时也在其 HTTP header 设置 Connection: keep-alive，则使用的 TCP 连接就会继续给其他 HTTP

TIME_WAIT的存在有两大理由 1.可靠地实现TCP全双工连接的终止 2.允许老的可重复分节在网络中消失。 对于理由1，我们知道TCP结束需要四次挥手，若最后一次的客户端的挥手ACK丢失（假设是客户端发起断开TCP连接）,服务器将重新发送它的最后那个FIN，因此客户必须维护状态信息，以允许它重新发送那个ACK（见下方例图1）。要是客户端不维护状态信息，它将响应一个RST(另一种类型的TCP分节)，该分节将被服务器解释成一个错误。如果TCP打算执行所有必要的工作以彻底终止某个链接上两个方向的数据流，那么它必须正确处理连接终止序列4个分节中任何一个分节丢失的情况。这个例子也说明了 为什么执行主动关闭的一端是处于TIME_WAIT状态的那一端：因为不得不重传最终ACK的就是那一端 。 　　　　　　　　　　　　　　　　 图1 对于第二个理由，我们假设在192.168.1.20的1500端口和46.19.0.201的21端口之间有一个TCP连接。我们关闭这个连接，过一段时间后在相同的IP和端口之间建立另一个连接。后一个连接称为前一个连接的化身，因为它们的IP地址和端口号都相同。TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现，被误认为属于同一个连接的某个新的化身。为做到这一点，TCP将不给处于TIEM_WAIT状态的连接发起新的化身。既然TIEM

TCP标志位 (参考来源： https://blog.csdn.net/ltstud/article/details/73995933 ) 6个标志位 SYN:(synchronous同步，建立联机) ACK:(acknowledgement 确认) PSH：(push传送) FIN(finish结束) RST(reset重置) URG(urgent紧急) 3次握手 主机A->主机B（第一次握手）： (可以建立连接吗？)发送位码为 syn＝1,seq number=1234567（随机产生）的数据包 到 服务器（主机B）；主机B收到 syn＝1后知道是a要建立连接； 主机B->主机A（第二次握手）：（可以建立连接。) 发送ack number=(主机A的seq+1),syn=1,ack=1，seq=7654321（随机产生）； 主机A->主机B（第三次握手）：（开始连接-->连接成功）（检查ack number？= （第一次握手seq）seq+1，ack？=1），若等于，发送ack number=(主机B（第二次握手）的seq+1),ack=1；主机B收到后确认（检查ack number？= （第二次握手seq）seq+1，ack？=1）后连接建立成功 四次挥手 由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。 但某一方的数据发送任务完后，给另一方发送一个FIN

Tcp连接断开的四次挥手 　　1 client端向server端发送FIN请求断开连接，client端进入FIN_WAIT_1状态，等待server端的ACK。此时客户端 不能发送数据，但仍然能够从server端读取数据。 　　2 server端收到FIN并发送了ACK之后，进入close_wait状态，不能够在读取数据，但仍然能向client发送数据。 　　3 client端收到了server端的ACK以后，进入FIN_WAIT_2状态，等待server端的FIN。server端发送FIN后进入 LAST_ACK状态，等待client端的ACK。 　　4 client端收到了server端FIN之后，并发送ACk之后，client端进入TIME_WAIT状态，等待2MSL。目的有两个 首选防止发送给server的ACK包丢失，确保连接正常关闭，第二个就是让重读的迷途分节在网络当中消逝。 　　　　　　　　　　　　 四次挥手的过程 常见问题： 1为什么连接的时候是三次握手，关闭的时候却是四次握手？ 　　因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，所以只能先回复一个ACK报文，告诉Client端，

TCP是什么 TCP(Transmission Control Protocol 传输控制协议)是一种面向连接(连接导向)的、可靠的、 基于IP的传输层协议。 TCP有6种标示:SYN(建立联机) ACK(确认) PSH(传送) FIN(结束) RST(重置) URG(紧急) TCP的三次握手 第一次握手：客户端向服务器发送请求报文，这时报文首部中的同部位SYN=1,并生成一个随机序列值seq=n。客户端进入syn-sent(同步已发送)状态，等待服务器确认 第二次握手：TCP服务器收到请求报文后，如果同意连接，则发出确认报文。确认报文中应该 ACK=1,SYN=1,确认号ACK=n+1,同时自己也随机生成一个seq=m，此时服务器进入SYN-RCVD(同步收到)状态。 第三次握手：TCP客户端进程收到确认后，还要向服务器给出确认。确认报文的ACK=1,ack=m+1, TCP的三次握手抓包 使用nc -l localhost 8088 监听8088端口 客户端使用nc -v localhost 8088 连接8088端口 再开个终端使用 tcpdump -i lo -vv -nnn tcp port 8088 抓包8088 端口tcp连接 抓包数据 为什么需要三次握手 端口 client发送了一个请求连接的报文，但是网络不好，这个请求没有立即达到服务端

TCP 是为了解决可靠传输出现的。为了实现可靠性，TCP 做了流量控制、拥塞控制，并且在建立、关闭连接前做些机制：三次握手、四次挥手。 三次握手是为了让客户端、服务器在建立连接前能保证相互可以发送、接收报文； 四次挥手也一样，客户端、服务器保证相互都得知要关闭时再关闭连接。 如果建立、关闭连接前没有做出这种保障，而直接发送报文或率先关闭，会出现报文丢失等风险。 （注意这里的保证不是指百分百的） ​ 那为什么是三次握手？而不是两次、四次？ 假如客户端 A、服务器 B，这里用打电话来做比喻： A 说：喂喂，听得到吗？ （B 听了之后，知道了自己能听到 A 讲的话。） B 回复说：可以。你能听得到吗？ （A 听了之后，他就能知道 B 可以听到自己的讲的话，并且自己也能听到 B。 但此时 B 还不知道 A 能不能听得到他自己说的话，所以 A 还要回复。） A 回复：嗯，听得到。 这时 A、B 便可以知道相互都能说、听，接下来可以开始聊了（即建立连接开始发送数据）。 如果是两次握手 从上面例子就能看出，如果只做两次握手，假如当 A 手机没电被关机时，B 就可能不知道情况而一直讲话。 所以，建立连接前，如果想可靠传输，必须要先保证相互能正常接收报文。 如果是四次握手 四次五次或者更多都可以，但这样其实会有点多余了。所以做三次握手即可。 ​ 为什么是四次挥手？而不是一次、两次、三次？

为什么会有TCP/IP协议 在世界上各地，各种各样的电脑运行着各自不同的操作系统为大家服务，这些电脑在表达同一种信息的时候所使用的方法是千差万别。就好像圣经中上帝打乱了各地人的口音，让他们无法合作一样。计算机使用者意识到，计算机只是单兵作战并不会发挥太大的作用。只有把它们联合起来，电脑才会发挥出它最大的潜力。于是人们就想方设法的用电线把电脑连接到了一起。 但是简单的连到一起是远远不够的，就好像语言不同的两个人互相见了面，完全不能交流信息。因而他们需要定义一些共通的东西来进行交流，TCP/IP就是为此而生。TCP/IP不是一个协议，而是一个协议族的统称。里面包括了IP协议，IMCP协议，TCP协议，以及我们更加熟悉的http、ftp、pop3协议等等。电脑有了这些，就好像学会了外语一样，就可以和其他的计算机终端做自由的交流了。 TCP/IP协议分层  TCP/IP协议族按照层次由上到下，层层包装。 应用层 : 向用户提供一组常用的应用程序，比如电子邮件、文件传输访问、远程登录等

本文通过图来梳理TCP-IP协议相关知识。TCP通信过程包括三个步骤：建立TCP连接通道，传输数据，断开TCP连接通道。如图1所示，给出了TCP通信过程的示意图。 图1 TCP 三次握手四次挥手 图1主要包括三部分：建立连接、传输数据、断开连接。 1)建立TCP连接很简单，通过三次握手便可建立连接。 2)建立好连接后，开始传输数据。TCP数据传输牵涉到的概念很多：超时重传、快速重传、流量控制、拥塞控制等等。 3)断开连接的过程也很简单，通过四次握手完成断开连接的过程。 三次握手建立连接： 第一次握手：客户端发送syn包(seq=x)到服务器，并进入SYN_SEND状态，等待服务器确认; 第二次握手：服务器收到syn包，必须确认客户的SYN(ack=x+1)，同时自己也发送一个SYN包(seq=y)，即SYN+ACK包，此时服务器进入SYN_RECV状态; 第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。 传输数据过程： a.超时重传 超时重传机制用来保证TCP传输的可靠性

TCP四次挥手 由于TCP连接时全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个FIN来终止这一方向的连接，收到一个FIN只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个TCP连接上仍然能够发送数据，直到这一方向也发送了FIN。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭，上图描述的即是如此。 （1）第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。 （2）第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入CLOSE_WAIT状态。 （3）第三次挥手：Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。 （4）第四次挥手：Client收到FIN后，Client进入TIME_WAIT状态，接着发送一个ACK给Server，确认序号为收到序号+1，Server进入CLOSED状态，完成四次挥手。 来源： https://www.cnblogs.com/luodalu/p/11954697.html

七、DNS DNS（Domain Name System，域名系统），因特网上作为域名和IP地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的IP数串。通过主机名，最终得到该主机名对应的IP地址的过程叫做域名解析（或主机名解析）。DNS协议运行在UDP协议之上，使用端口号53。 八、TCP连接的建立与终止 1.三次握手 TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。 第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认； 第二次握手： 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态； 第三次握手：