tcp被动连接(tcp主动连接和被动连接)

传输控制协议( TCP ) 是Internet 协议套件的主要协议之一。起源于最初的网络实现，它补充了Internet 协议(IP)。因此，整个套件通常称为TCP/IP。TCP在通过 IP 网络通信的主机上运行的应用程序之间提供可靠的、有序的和经过错误检查的八位位组（字节）流传输。主要的互联网应用程序，例如万维网、电子邮件、远程管理和文件传输依赖于 TCP，它是TCP/IP 套件传输层的一部分。SSL/TLS通常运行在 TCP 之上。TCP 是面向连接的，在发送数据之前，客户端和服务器之间建立了连接。在建立连接之前，服务器必须正在侦听（被动打开）来自客户端的连接请求。三向握手（主动打开）、重传和错误检测增加了可靠性，但延长了延迟。不需要可靠数据流服务的应用程序可以使用用户数据报协议(UDP)，它提供了一种无连接 数据报服务，它优先考虑时间而不是可靠性。TCP 采用网络拥塞避免。但是，TCP 存在漏洞，包括拒绝服务、连接劫持、TCP 否决和重置攻击。网络功能传输控制协议在应用程序和 Internet 协议之间提供中间级别的通信服务。它在Internet 模型的传输层提供主机到主机的连接。应用程序不需要知道通过链接将数据发送到另一台主机的特定机制，例如为容纳传输介质的最大传输单元所需的IP 分段。在传输层，TCP 处理所有握手和传输细节，并通常通过网络套接字接口向应用程序提供网络连接的抽象。在协议栈的较低级别，由于网络拥塞、流量负载平衡或不可预测的网络行为，IP 数据包可能会丢失、重复或乱序传送。TCP 检测到这些问题，请求重新传输丢失的数据，重新排列乱序数据，甚至帮助最小化网络拥塞以减少其他问题的发生。如果数据仍未交付，则会通知源此失败。一旦 TCP 接收器重新组合了最初传输的八位字节序列，它就会将它们传递给接收应用程序。因此，TCP从底层网络细节中 抽象出应用程序的通信。

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

TCP是面向连接的协议。运输连接是用来传送TCP报文的。TCP运输连接的建立和释放是每一次连接通信过程中必不可少的。因此，运输连接就有三个阶段：连接建立，数据传送和连接释放。需要解决以下3个问题：连接建立这个过程，需要在客户端和服务器之间，交换3个TCP报文段，也就是三次握手????x3。????请注意，在本例中，A主动打开连接，B被动打开连接一开始，B就在准备接受客户进程的连接请求，然后服务器进程就处于 LISTEN （收听）状态，等待客户的连接请求。如有，即作出响应。A的TCP客户进程像B发出连接请求报文段，这时，首部中的同步位SYN = 1，同时选择一个初始序号 seq = x 。TCP规定????，SYN报文段不能携带数据，但要消耗掉一个序号。这时，TCP客户进程进入SYN-SENT（同步已发送）状态。B收到连接请求的报文段后，如同意建立连接，则向A发送确认。在确认报文段中，应把SYN位和ASK位都置1，确认号是 ack = x + 1 ，同时也为自己选择一个初始序号 seq = y 。请注意，这个报文段也不能携带数据。但同样要消耗掉一个序号。这时，TCP服务器进程进入SYN-RCVD（同步收到）状态。TCP客户进程收到B的确认后，还要向B给出确认。确认报文段的ACK置1，确认号 ack = y + 1 ，而自己的序号 seq = x + 1 。TCP的标准规定????，ACK报文段可以携带数据。但如果不携带数据则不消耗序号，在这种情况下，下一个数据报文段的序号仍是 seq = x +1 。这时，TCP连接已经建立????，A进入ESTABLISHED（已建立连接）状态。当B收到A的确认后，也进入ESTABLISHED（已建立连接）???? Q:为什么A最后还有发送一次确认呢？????A:主要是为了防止已失效的连接请求报文段突然又传送到B，因而产生错误。所谓“已失效的连接请求报文段”是这样产生的。????考虑一种正常情况，A 发出连接请求????，但因连接请求报文丢失而未收到确认。于是A再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A共发出了两个连接请求的报文段，其中第一个丢失????，第二个到达了B????，没有“已失效的连接请求报文段”。????现假定出现一种异常情况，即A发出的第一个连接请求报文段并没有丢失，而是在某个网络节点长时间的滞留????，以至延误到连接释放以后的某个时间才到达B。本来这是一个 早已失效的报文段 ，但是B收到此时小的连接请求的报文段之后，误以为是A又发出一次新的连接请求。于是向A发出确认报文段，同意建立连接。假定不采用报文握手。那么只要B发出确认之后，新的连接就建立了。由于现在A并没有发出建立连接的请求，因此不会理睬B的确认????，也不会向B发送数据，但B确以为新的运输连接已经建立，并一直等待A发来的数据。B的许多资源就这样白白浪费了。

主动打开的的一方称为客户端，被动打开的一端称为服务端。 主动打开就是指利用TCP报文请求建立连接的一方。就比如你给别人打电话，你先拨号，你就是主动打开。 被动打开就是接受的另一方的请求报文并同意建立连接的一方。就比如你给别人打电话过去，对方接听了，打就是被动打开。

目录：以前我也认为TCP是相当底层的东西，我永远不需要去了解它。虽然差不多是这样，但是实际生活中，你依然可能遇见和TCP算法相关的bug，这时候懂一些TCP的知识就至关重要了。（本文也可以引申为，系统调用，操作系统这些都很重要，这个道理适用于很多东西）这里推荐一篇小短文， 人人都应该懂点TCP使用TCP协议通信的双方必须先建立TCP连接，并在内核中为该连接维持一些必要的数据结构，比如连接的状态、读写缓冲区、定时器等。当通信结束时，双方必须关闭连接以释放这些内核数据。TCP服务基于流，源源不断从一端流向另一端，发送端可以逐字节写入，接收端可以逐字节读出，无需分段。需要注意的几点：TCP状态（11种）：eg.以上为TCP三次握手的状态变迁以下为TCP四次挥手的状态变迁服务器通过 listen 系统调用进入LISTEN状态，被动等待客户端连接，也就是所谓的被动打开。一旦监听到SYN（同步报文段）请求，就将该连接放入内核的等待队列，并向客户端发送带SYN的ACK（确认报文段），此时该连接处于SYN_RECVD状态。如果服务器收到客户端返回的ACK，则转到ESTABLISHED状态。这个状态就是连接双方能进行全双工数据传输的状态。而当客户端主动关闭连接时，服务器收到FIN报文，通过返回ACK使连接进入CLOSE_WAIT状态。此状态表示——等待服务器应用程序关闭连接。通常，服务器检测到客户端关闭连接之后，也会立即给客户端发送一个FIN来关闭连接，使连接转移到LAST_ACK状态，等待客户端对最后一个FIN结束报文段的最后一次确认，一旦确认完成，连接就彻底关闭了。客户端通过 connect 系统调用主动与服务器建立连接。此系统调用会首先给服务器发一个SYN，使连接进入SYN_SENT状态。connect 调用可能因为两种原因失败：1. 目标端口不存在（未被任何进程监听）护着该端口被TIME_WAIT状态的连接占用（ 详见后文 ）。2. 连接超时，在超时时间内未收到服务器的ACK。如果 connect 调用失败，则连接返回初始的CLOSED状态，如果调用成功，则转到ESTABLISHED状态。客户端执行主动关闭时，它会向服务器发送一个FIN，连接进入TIME_WAIT_1状态，如果收到服务器的ACK，进入TIME_WAIT_2状态。此时服务器处于CLOSE_WAIT状态，这一对状态是可能发生办关闭的状态（详见后文）。此时如果服务器发送FIN关闭连接，则客户端会发送ACK进行确认并进入TIME_WAIT状态。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。如果网络出现拥塞，分组将会丢失，此时发送方会继续重传，从而导致网络拥塞程度更高。因此当出现拥塞时，应当控制发送方的速率。这一点和流量控制很像，但是出发点不同。流量控制是为了让接收方能来得及接收，而拥塞控制是为了降低整个网络的拥塞程度。TCP 主要通过四种算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复。在Linux下有多种实现，比如reno算法，vegas算法和cubic算法等。发送方需要维护一个叫做拥塞窗口（cwnd）的状态变量，注意拥塞窗口与发送方窗口的区别：拥塞窗口只是一个状态变量，实际决定发送方能发送多少数据的是发送方窗口。为了便于讨论，做如下假设：发送的最初执行慢开始，令 cwnd=1，发送方只能发送 1 个报文段；当收到确认后，将 cwnd 加倍，因此之后发送方能够发送的报文段数量为：2、4、8 ...注意到慢开始每个轮次都将 cwnd 加倍，这样会让 cwnd 增长速度非常快，从而使得发送方发送的速度增长速度过快，网络拥塞的可能也就更高。设置一个慢开始门限 ssthresh，当 cwnd >= ssthresh 时，进入拥塞避免，每个轮次只将 cwnd 加 1。如果出现了超时，则令 ssthresh = cwnd/2，然后重新执行慢开始。在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd/2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。发送端的每个TCP报文都必须得到接收方的应答，才算传输成功。TCP为每个TCP报文段都维护一个重传定时器。发送端在发出一个TCP报文段之后就启动定时器，如果在定时时间类未收到应答，它就将重发该报文段并重置定时器。因为TCP报文段最终在网络层是以IP数据报的形式发送，而IP数据报到达接收端可能是乱序或者重复的。TCP协议会对收到的TCP报文进行重排、整理，确保顺序正确。TCP报文段所携带的应用程序数据按照长度分为两种：交互数据和成块数据对于什么是粘包、拆包问题，我想先举两个简单的应用场景：对于第一种情况，服务端的处理流程可以是这样的：当客户端与服务端的连接建立成功之后，服务端不断读取客户端发送过来的数据，当客户端与服务端连接断开之后，服务端知道已经读完了一条消息，然后进行解码和后续处理...。对于第二种情况，如果按照上面相同的处理逻辑来处理，那就有问题了，我们来看看第二种情况下客户端发送的两条消息递交到服务端有可能出现的情况：第一种情况：服务端一共读到两个数据包，第一个包包含客户端发出的第一条消息的完整信息，第二个包包含客户端发出的第二条消息，那这种情况比较好处理，服务器只需要简单的从网络缓冲区去读就好了，第一次读到第一条消息的完整信息，消费完再从网络缓冲区将第二条完整消息读出来消费。第二种情况：服务端一共就读到一个数据包，这个数据包包含客户端发出的两条消息的完整信息，这个时候基于之前逻辑实现的服务端就蒙了，因为服务端不知道第一条消息从哪儿结束和第二条消息从哪儿开始，这种情况其实是发生了TCP粘包。第三种情况：服务端一共收到了两个数据包，第一个数据包只包含了第一条消息的一部分，第一条消息的后半部分和第二条消息都在第二个数据包中，或者是第一个数据包包含了第一条消息的完整信息和第二条消息的一部分信息，第二个数据包包含了第二条消息的剩下部分，这种情况其实是发送了TCP拆，因为发生了一条消息被拆分在两个包里面发送了，同样上面的服务器逻辑对于这种情况是不好处理的。我们知道tcp是以流动的方式传输数据，传输的最小单位为一个报文段（segment）。tcp Header中有个Options标识位，常见的标识为mss(Maximum Segment Size)指的是，连接层每次传输的数据有个最大限制MTU(Maximum Transmission Unit)，一般是1500比特，超过这个量要分成多个报文段，mss则是这个最大限制减去TCP的header，光是要传输的数据的大小，一般为1460比特。换算成字节，也就是180多字节。tcp为提高性能，发送端会将需要发送的数据发送到缓冲区，等待缓冲区满了之后，再将缓冲中的数据发送到接收方。同理，接收方也有缓冲区这样的机制，来接收数据。发生TCP粘包、拆包主要是由于下面一些原因：既然知道了tcp是无界的数据流，且协议本身无法避免粘包，拆包的发生，那我们只能在应用层数据协议上，加以控制。通常在制定传输数据时，可以使用如下方法：写了一个简单的 golang 版的tcp服务器实例，仅供参考：例子参考和推荐阅读书目：注释：eg.