tcp全双工吗(Tcp全双工)

title: TCP 总结date: 2018-03-25 09:40:24tags:categories:-计算机网络我们都知道 TCP 是位于传输层的协议，他还有一个兄弟就是 UDP ，他们两共同构成了传输层。显然他们之间有很大的区别要不然的话在传输层只需要一个就好了。其中最重要的区别就是一个面向连接另外一个不是，这个区别就导致了他们是否能够保证稳定传输，显然不面向连接的 UDP 是没办法保证可靠传输的，他只能靠底层的网络层和链路层来保证。我们都知道网络层采用的是不可靠的 IP 协议。好吧，网络层也保证不了可靠传输，所以 UDP 保证可靠传输只能依靠链路层了。而 TCP 就好说了他不仅仅有底层的链路层的支持，还有自己的面向链接服务来保证可靠传输。当然 TCP也不仅仅就是比 UDP 多了一个可靠传输，前面也说到了这只是他们之间一个重要的区别。其实他的三个重要特性就是它们之间的区别。* 可靠传输* 流量控制* 拥塞控制TCP 主要是 确认重传机制 数据校验 数据合理分片和排序 流量控制 拥塞控制 依靠来完成可靠传输的 , 下面详细介绍这几种保证可靠传输的方式。确认重传，简单来说就是接收方收到报文以后给发送方一个 ACK 回复，说明自己已经收到了发送方发过来的数据。如果发送方等待了一个特定的时间还没有收到接收方的 ACK 他就认为数据包丢了，接收方没有收到就会重发这个数据包。好的，上面的机制还是比较好理解的，但是我们会发现一个问题，那就是如果接收方已经收到了数据然后返回的 ACK 丢失，发送方就会误判导致重发。而此时接收方就会收到冗余的数据，但是接收方怎么能判定这个数据是冗余的还是新的数据呢？这就涉及到了 TCP 的另外一个机制就是采用序号和确认号，也就是每次发送数据的时候这个报文段里面包括了当前报文段的序号和对上面的报文的确认号，这样我们的接收方可以根据自己接受缓存中已经有的数据来确定是否接受到了重复的报文段。这时候如果出现上面所说的 ACK 丢失，导致接受重复的报文段时客户端丢弃这个冗余的报文段。好现在我们大致了解了确认重传机制，但是还有些东西还没有弄清楚，也就是 TCP 真正的实现究竟是怎样的。这就是我们要解决的第一个问题就是如何确认。这里涉及到两种确认方式，分别称为 累计确认（捎带确认）和单停等协议。用一张图来快速理解，就是每发送一次数据，就进行一次确认。等发送方收到了 ACK 才能进行下一次的发送。一样的也是采用的 ACK 机制，但是注意一点的是，并非对于每一个报文段都进行确认，而仅仅对最后一个报文段确认，捎带的确认了上图中的 203 号及以前的报文。总结：从上面可以看到累计确认的效率更加高，首先他的确认包少一些那么也就是在网络中出现的大部分是需要传输的数据，而不是一半的数据一半的 ACK ，然后我们在第二张图中可以看到我们是可以连续发送多个报文段的（究竟一次性能发多少这个取决于发送窗口，而发送窗口又是由接受窗口和拥塞窗口一起来决定的。），一次性发多个数据会提高网络的吞吐量以及效率这个可以证明，比较简单这里不再赘述！结论：显然怎么看都是后者比较有优势，TCP 的实现者自然也是采用的累计确认的方式！上文中的那个特定的时间就是超时时间，为什么有这个值呢? 其实在发送端发送的时候就为数据启动了一个定时器，这个定时器的初始值就是超时时间。超时时间的计算其实有点麻烦，主要是我们很难确定一个确定的值，太长则进行了无意义的等待，太短就会导致冗余的包。TCP 的设计者们设计了一个计算超时时间的公式，这个公式概念比较多，有一点点麻烦，不过没关系我们一点点的来。首先我们自己思考如何设计一个超时时间的计算公式，超时时间一般肯定是和数据的传输时间有关系的，他必然要大于数据的往返时间（数据在发送端接收端往返一趟所用的时间）。好，那么我们就从往返时间下手，可是又有一个问题就是往返时间并不是固定的我们有如何确定这个值呢？自然我们会想到我们可以取一小段时间的往返时间的平均值来代表这一时间点的往返时间，也就是微积分的思想！好了我们找到了往返时间（RTT），接下来的超时时间应该就是往返时间再加上一个数就能得到超时时间了。这个数也应该是动态的，我们就选定为往返时间的波动差值，也就是相邻两个往返时间的差。下面给出我们所预估的超时时间（TimeOut）公式：很好，看到这里其实你已经差不多理解了超时时间的计算方式了，只不过我们这个公式不够完善，但是思路是对的。我们这时候来看看 TCP 的实现者们采用的方式。好的，这就是 TCP 实现的超时时间的方式，但是在实际的应用中并不是一直采用的这种方式。假如说我们现在网络状态非常的差，一直在丢包我们根本没必要这样计算，而是采用直接把原来的超时时间加倍作为新的超时时间。总结：好的现在我们知道了在两种情况下的超时时间的计算方式，正常的情况下我们采用的上面的比较复杂的计算公式，也就是RTT+波动值否则直接加倍上面我们看到在发送方等待一个超时重传时间后会开始重传，但是我们计算的超时重传时间也不定就很准，也就是说我们经常干的一件事就会是等待，而且一般等的时间还挺长。那么可不可以优化一下呢？当然，在 TCP 实现中是做了优化的，也就是这里说到的快速重传机制。他的原理就是在发送方收到三个冗余的 ACK 的时候，就开始重传那个报文段。那么为什么是三个冗余的 ACK 呢？注意三个冗余的 ACK 其实是四个 ACK 。我们先了解一下发送 ACK 策略，这个是RFC 5681 文档规定的。好的，那么现在我们可以看到如果出现了三个冗余的 ACK 他只可能是发生了两次情况三，也就是发送了两个比期望值大的数据。但是注意出现情况三有两种可能，一个是丢包，另外一个是乱序到达。比如说我们现在是数据乱序到达的，我们来看一下。第一种乱序情况另外一种乱序丢包情况结论: 很显然我们可以看到，如果发生了乱序有可能会出现三次冗余 ACK，但是如果发现了丢包必然会有三次冗余 ACK 发生，只是 ACK 数量可能更多但是不会比三次少在我们发现丢包以后我们需要重传，但是我们重传的方式也有两种方式可以选择分别是GBN和SR翻译过来就是拉回重传和选择重传。好其实我们已经能从名字上面看出来他们的作用方式了，拉回重传就是哪个地方没收到那么就从那个地方及以后的数据都重新传输，这个实现起来确实很简单，就是把发送窗口和接受窗口移回去，但是同样的我们发现这个方式不实用干了很多重复的事，效率低。那么选择重传就是你想到的谁丢了，就传谁。不存在做无用功的情况。结论:TCP 实际上使用的是两者的结合，称为选择确认，也就是允许 TCP 接收方有选择的确认失序的报文段，而不是累计确认最后一个正确接受的有序报文段。也就是跳过重传那些已经正确接受的乱序报文段。数据校验，其实这个比较简单就是头部的一个校验，然后进行数据校验的时候计算一遍 checkSum 比对一下。在 UDP 中，UDP 是直接把应用层的数据往对方的端口上 “扔” ，他基本没有任何的处理。所以说他发给网络层的数据如果大于1500字节,也就是大于MTU。这个时候发送方 IP 层就需要分片。把数据报分成若干片，使每一片都小于MTU.而接收方IP层则需要进行数据报的重组。这样就会多做许多事情,而更严重的是 ，由于UDP的特性,当某一片数据传送中丢失时 ， 接收方便无法重组数据报，将导致丢弃整个UDP数据报。而在 TCP 中会按MTU合理分片，也就是在 TCP 中有一个概念叫做最大报文段长度（MSS）它规定了 TCP 的报文段的最大长度，注意这个不包括 TCP 的头，也就是他的典型值就是 1460 个字节（TCP 和 IP 的头各占用了 20 字节）。并且由于 TCP 是有序号和确认号的，接收方会缓存未按序到达的数据，根据序号重新排序报文段后再交给应用层。流量控制一般指的就是在接收方接受报文段的时候，应用层的上层程序可能在忙于做一些其他的事情，没有时间处理缓存中的数据，如果发送方在发送的时候不控制它的速度很有可能导致接受缓存溢出，导致数据丢失。相对的还有一种情况是由于两台主机之间的网络比较拥塞，如果发送方还是以一个比较快的速度发送的话就可能导致大量的丢包，这个时候也需要发送方降低发送的速度。虽然看起来上面的两种情况都是由于可能导致数据丢失而让发送主机降低发送速度，但是一定要把这两种情况分开，因为前者是属于 流量控制而后者是拥塞控制，那将是我们后面需要讨论的事情。不要把这两个概念混了。其实说到流量控制我们就不得不提一下滑动窗口协议，这个是流量控制的基础。由于 TCP 连接是一个全双工的也就是在发送的时候也是可以接受的，所以在发送端和接收端同时维持了发送窗口和接收窗口。这里为了方便讨论我们就按照单方向来讨论。接收方维持一个接受窗口，发送方一个发送窗口。发送的时候要知道接受窗口还有多少空间，也就是发送的数据量不能超过接受窗口的大小，否则就溢出了。而当我们收到一个接收方的 ACK 的时候我们就可以移动接受窗口把那些已经确认的数据滑动到窗口之外，发送窗口同理把确认的移出去。这样一直维持两个窗口大小，当接收方不能在接受数据的时候就把自己的窗口大小调整为 0 发送窗口就不会发送数据了。但是有一个问题，这个时候当接收窗口再调大的时候他不会主动通知发送方，这里采用的是发送方主动询问。还是画个图看的比较直观：拥塞控制一般都是由于网络中的主机发送的数据太多导致的拥塞，一般拥塞的都是一些负载比较高的路由，这时候为了获得更好的数据传输稳定性，我们必须采用拥塞控制，当然也为了减轻路由的负载防止崩溃。这里主要介绍两个拥塞控制的方法，一个是慢开始，另外一个称为快恢复。那么问题来了，为什么需要序号呢？为什么又是三次握手而不是两次？以及什么是 SYN 洪泛攻击？这里需要说明一下的是最后的那个长长的 TIME_WAIT 状态一般是为了客户端能够发出 ACK 一般他的值是 1分钟 或者2分钟好了，今天真的写了不少，主要就是把 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

三次握手(建立连接) 1)客户端发送一个带SYN标志的TCP报文到服务器，这是第1个报文;2)服务端回应客户端，是第2个报文，同时带有ACK标志和SYN标志，以此回应第1步，SYN用于询问客户端是否准备好进行通讯;3)客户再次回应服务端一个ACK报文，是第3个报文。为什么要进行3次握手?当服务端的LISTEN状态下的SOCKET收到SYN报文的请求后，可以把ACK和SYN放在1个报文中来发送，其中ACK的作用是应答，而SYN的作用是同步。四次挥手(连接终止协议)1)TCP客户端发哦是那个一个FIN，用于关闭客户发送到服务器的数据传送;2)服务器收到这个FIN，返回一个ACK，和SYN一样，一个FIN将占用一个序号;3)服务器关闭客户端的连接，发送FIN给客户端;4)客户端返回ACK报文，并将确认序号设置为收到的序号+1。为什么要进行4次挥手? 在TCP连接时，是将SYN和ACK一起发送的，但为什么挥手却没有一起发送呢?因为TCP是全双工模式，接收到FIN时将没有数据再发来，但还是可以继续发送数据。
安全考虑，需要通信双方确认

在介绍TCP和UDP协议之前，有必要先了解下TCP/IP模型，TCP/IP中的两个具有代表性的传输协议：TCP和UDP。 TCP/IP 是互联网相关的各类协议族的总称，比如：TCP，UDP，IP，FTP，HTTP，ICMP，SMTP 等都属于 TCP/IP 族内的协议。TCP/IP模型是互联网的基础，它是一系列网络协议的总称。这些协议可以划分为四层，分别为链路层、网络层、传输层和应用层。TCP协议全称是传输控制协议，是一种面向连接、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。流就是指不间断的数据结构，可以想象成水管中的水流。TCP 在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的运输服务（TCP 的可靠体现在 TCP 在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。最初客户端和服务端都处于CLOSED（关闭）状态，客户端主动打开连接，服务端被动打开连接。--- 为了防止已经失效的连接请求又突然被服务端接收，从而产生错误。比如：A发出的第一个连接请求报文段并没有丢失，而是在网络结点时间长了，以致于延误到连接释放以后的某个时间段才到达B，但是B收到此失效的请求后，就误以为A又发出一次新的连接请求，于是就向A发出确认报文段，同意建立连接。出现失效的连接请求报文段被服务端接收的情况，从而产生错误。UDP协议全称是用户数据报协议，在网络中它与TCP协议一样用于处理数据包，是一种无连接的协议。在OSI模型中，在第四层——传输层，处于IP协议的上一层。UDP有不提供数据包分组、组装和不能对数据包进行排序的缺点，也就是说，当报文发送之后，是无法得知其是否安全完整到达的。UDP在传送数据之前不需要建立连接，远地主机在收到UDP报文后，不需要给出任何确认。虽然UDP不提供可靠交付，但在某些情况下，UDP却是最有效的一种比如QQ语音、QQ视频、直播等即时通信应用。因此 UDP 的头部开销小，只有八字节，相比 TCP 的至少二十字节要少得多，在传输数据报文时是很高效的1、连接的区别TCP面向连接，即发送数据之前先建立连接。UDP是无连接的，即发送数据之前是不需要建立连接的。2、安全方面的区别TCP是全双工的可靠通信，提供可靠的服务，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达。使用流量控制和拥塞控制。UDP是不可靠传输，尽最大努力交付，即不保证可靠交付。3、传输效率的区别TCP传输效率较低。UDP传输效率高，适用于对高速传输和实时性有较高要求的通信或广播通信。4、连接对象数量的区别TCP连接只能是点到点，一对一的。UDP支持一对一，一对多，多对一和多对多的交互通信。5、传输方式的区别TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流。适用于要求可靠传输的应用比如文件传输等。UDP面向报文，没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低，对实时应用很有用比如实时视频会议等。6、首部开销TCP首部开销最小20字节，最大60字节。 UDP首部开销小，只有8个字节。

unix的哲学是一切皆文件，可以把socket看成是一种特殊的文件，而一些socket函数就是对其进行的操作api（读/写IO、打开、关闭）。我们知道普通文件的打开操作（open）返回一个文件描述字，与之类似，socket()用于创建一个socket描述符（socket descriptor），它唯一标识一个socket。当我们调用socket创建一个socket时，返回的socket描述字它存在于协议族（address family，AF_XXX）空间中，但没有一个具体的地址。如果想要给它赋值一个地址，就必须调用bind()函数，sockfd即socket描述字，它是通过socket()函数创建了，唯一标识一个socket。bind()函数就是将给这个描述字绑定一个名字。在将一个地址绑定到socket的时候，需要先将主机字节序转换成为网络字节序，而不要假定主机字节序跟网络字节序一样使用的是Big-Endian。由于这个问题曾引发过不少血案，谨记对主机字节序不要做任何假定，务必将其转化为网络字节序再赋给socket。这里的主机字节序就是我们平常说的大端和小端模式：不同的CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序，这个叫做主机序。引用标准的Big-Endian和Little-Endian的定义如下：listen函数的第一个参数即为要监听的socket描述字，第二个参数为socket可以接受的排队的最大连接个数。listen函数表示等待客户的连接请求。connect函数的第一个参数即为客户端的socket描述字，第二参数为服务器的socket地址，第三个参数为socket地址的长度。客户端通过调用connect函数来建立与TCP服务器的连接。TCP服务器端依次调用socket()、bind()、listen()之后，就会监听指定的socket地址了。TCP客户端依次调用socket()、connect()之后就向TCP服务器发送连接请求。TCP服务器监听到这个请求之后，就会调用accept()函数去接收请求，这样连接就建立好了(在connect之后就建立好了三次连接)，之后就可以开始进行类似于普通文件的网络I/O操作了。如果accpet成功，那么其返回值是由内核自动生成的一个全新的描述字，代表与客户的TCP连接。accept的第一个参数为服务器的socket描述字，是服务器开始调用socket()函数生成的，称为监听socket描述字；而accept函数返回的是已连接的socket描述字。一个服务器通常通常仅仅只创建一个监听socket描述字，它在该服务器的生命周期内一直存在。内核为每个由服务器进程接受的客户连接创建了一个已连接socket描述字，当服务器完成了对某个客户的服务，相应的已连接socket描述字就被关闭。read函数是负责从fd中读取内容.当读成功时，read返回实际所读的字节数，如果返回的值是0表示已经读到文件的结束了，小于0表示出现了错误。如果错误为EINTR说明读是由中断引起的，如果是ECONNREST表示网络连接出了问题。write函数将buf中的nbytes字节内容写入文件描述符fd.成功时返回写的字节数。失败时返回-1，并设置errno变量。 在网络程序中，当我们向套接字文件描述符写时有俩种可能。1)write的返回值大于0，表示写了部分或者是全部的数据。2)返回的值小于0，此时出现了错误在服务器与客户端建立连接之后，会进行一些读写操作，完成了读写操作就要关闭相应的socket描述字，类似于操作完打开的文件要调用fclose关闭打开的文件。close一个TCP socket的缺省行为时把该socket标记为已关闭，然后立即返回到调用进程。该描述字不能再由调用进程使用，也就是说不能再作为read或write的第一个参数close操作只是使相应socket描述字的引用计数-1，只有当引用计数为0的时候，才会触发TCP客户端向服务器发送终止连接请求。我们知道tcp建立连接要进行“三次握手”，即交换三个分组。大致流程如下：客户端向服务器发送一个SYN J服务器向客户端响应一个SYN K，并对SYN J进行确认ACK J+1客户端再想服务器发一个确认ACK K+1socket中TCP的四次握手释放连接详解某个应用进程首先调用close主动关闭连接，这时TCP发送一个FIN M；另一端接收到FIN M之后，执行被动关闭，对这个FIN进行确认。一段时间之后，服务端调用close关闭它的socket。这导致它的TCP也发送一个FIN N；接收到这个FIN的源发送端TCP对它进行确认,这样每个方向上都有一个FIN和ACK。为什么要三次握手由于tcp连接是全双工的，存在着双向的读写通道，每个方向都必须单独进行关闭。当一方完成它的数据发送任务后就可以发送一个FIN来终止这个方向的连接。收到FIN只意味着这个方向上没有数据流动，但并不表示在另一个方向上没有读写，所以要双向的读写关闭需要四次握手，3. time_wait状态如何避免？首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。1.客户端连接服务器的80服务，这时客户端会启用一个本地的端口访问服务器的80，访问完成后关闭此连接，立刻再次访问服务器的80，这时客户端会启用另一个本地的端口，而不是刚才使用的那个本地端口。原因就是刚才的那个连接还处于TIME_WAIT状态。2.客户端连接服务器的80服务，这时服务器关闭80端口，立即再次重启80端口的服务，这时可能不会成功启动，原因也是服务器的连接还处于TIME_WAIT状态。实战分析：状态描述：CLOSED：无连接是活动的或正在进行LISTEN：服务器在等待进入呼叫SYN_RECV：一个连接请求已经到达，等待确认SYN_SENT：应用已经开始，打开一个连接ESTABLISHED：正常数据传输状态FIN_WAIT1：应用说它已经完成FIN_WAIT2：另一边已同意释放ITMED_WAIT：等待所有分组死掉CLOSING：两边同时尝试关闭TIME_WAIT：另一边已初始化一个释放LAST_ACK：等待所有分组死掉命令解释：如何尽量处理TIMEWAIT过多?编辑内核文件/etc/sysctl.conf，加入以下内容：net.ipv4.tcp_syncookies = 1 表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少量SYN攻击，默认为0，表示关闭；net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接，默认为0，表示关闭；net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收，默认为0，表示关闭。net.ipv4.tcp_fin_timeout 修改系默认的 TIMEOUT 时间然后执行 /sbin/sysctl -p 让参数生效./etc/sysctl.conf是一个允许改变正在运行中的Linux系统的接口，它包含一些TCP/IP堆栈和虚拟内存系统的高级选项，修改内核参数永久生效。简单来说，就是打开系统的TIMEWAIT重用和快速回收。本文主要讲述了socket的主要api，以及tcp的连接过程和其中各个阶段的连接状态，理解这些是更深入了解tcp的基础！