tcp有没有连接(tcp长连接如何实现)

通过设置linux参数 net.ipv4.tcp_fin_timeout = 30 ，可以调整如发现系统存在大量TIME_WAIT状态的连接，通过调整内核参数解决：编辑文件/etc/sysctl.conf，加入以下内容tcp 通过序列号seq记录已经发送的数据刻度，通过ack记录已经接收的数据量。seq记录的是发送的数据，ack记录的是接收的数据量。单位是字节（8bit）tcp在每次发包时都会计算往复时间及其偏差。将这个往返时间和偏差相加，重发超时时间就是比这个总和要稍大一点的值。由于最初的数据包还不知道往返时间，所以其重发超时一般设置为6s左右。在建立tcp连接时，三次握手的时候会计算mss（最大消息长度），建立连接的双方会把自己的接口能适应的mss值放到tcp首部里面发送给对方，最后取较小的那个mss。tcp窗口大小指的是无需等待确认应答而可以继续发送数据的最大值，窗口大小为4个端。即在收到确认应答之前可以发送的数据的段数。接收端没有按序列顺序收到数据端时，会不停的发送确认应答，并将当前收到的顺序出问题的数据放到缓冲区。发送端连续三次收到相同序列号的数据段时，会重新发送该段的数据。接收端在接收到遗失的数据的时候会将数据与缓冲区的数据组合，重新按顺序确定ack的序列号，继续接收数据。tcp窗口的大小是由接收端的处理能力决定的，接收端会在ack的tcp首部中将能处理的窗口大小传给发送端。拥塞窗口是限制每次发送的数据的大小，初始值是1mss，也就是慢启动。随着正常的收发的进行，拥塞窗口的值会不断的增加。但是不会超过接收端处理窗口的大小。一开始拥塞窗口每次都会翻倍的增长，在超过慢启动阈值后增长速度会减慢。增长速率=一个数据段的大小 / 拥塞窗口的大小 *一个数据段的大小超时重发时，拥塞窗口会变为1mss， 慢启动阈值为原有窗口的一半重复确认应答时，慢启动阈值为原有窗口的一半，拥塞窗口会变为慢启动阈值+3数据端，1、已发送的数据收到了ack回执2、可以发送mss大小的数据时只有以上两个数据都满足时才发送数据。会有延迟，对延迟敏感的需求可以关。1、收到2*最大端长度的数据2、最大延迟0.5s发送确认应答将tcp的确认应答和回执数据通过一个包发送。接收数据之后等待应用处理生成返回数据以后在发送回复时同时发送回执。需要开启延迟确认应答。

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连接"，"服务器的连接数量有限"等，但仔细一想，连接究竟是个什么东西，是和电话一样两端连起一根线？似乎有点抽象不是么？ 1.久违的分组交换网络似乎这个概念只有在学校里学计算机网络才能接触到，但不过今天的话题其实和它离不开关系。我们知道最早的电话网络是以很容易理解的形式存在的，就是单纯的一根线加两端的设备，设备之间所沟通的所有信息都通过一根特定的电缆来回传输，如下图：这样的连接是我们特别好理解的，搭起两边的线，就是一个连接嘛！但是，我们讨论的是计算机网络！(严肃脸)，计算机网络中两个设备节点是如何通信？计算机网络采取分组交换技术，什么意思呢？就是我有【一块数据】要发给对方小苍，那我会把这【一块数据】分成N份【单位数据】，分别发出去，而每份【单位数据】走哪条路是不一定的，但是这些【单位数据】总要全部达到小苍手里，小苍再根据【单位数据】里记录的序号拼接起来，组成完整的【一块数据】。这就是分组的意思所在。2.协议和协议实现上面不小心把TCP的大体实现给说了，实际上在具体的应用中，光有大体思路是不行的，还有很多细节问题，需要两个设备之间提前约定好协议，才能协同完成通信。举个例子：A向B发了10份【单位数据】，而B其实只收到9份【单位数据】，怎么办？TCP协议大家都应该是知道的，但协议只是想法，真正起作用的是在路由节点和设备节点上的协议软件，是运行在设备上的具体执行者，它根据协议指导，对具体数据进行控制和操作。这儿就不往下展开了。认识到协议和协议软件这一点非常重要，因为连接的限制恰恰就是受软件在设备中资源分配的影响的。3.连接的真面目上面说的第一种电话网络，如果两个设备搭设了一条线，那么两个电话就一定确定对方在线，因为他俩独享一条实时存在的线。但计算机网络的连接呢？向上面的图一样(图里不深究TCP，仅仅用来说明连接大体过程)，其实他们俩并不能确保对方就是在线，只是通过几番确认，认为对方一直会在。而如果确认了对方存在，那么就会为以后的对话通讯分配内存、CPU处理时间等资源，每个设备都会在本地去维持这么一个状态，来告诉自己是有一个连接的，这些设备所花的资源和维护的状态，就是连接。而整个网络是不会记录有着一条连接的，所以说连接只是记录在各个设备的一个状态信息。那么，到现在我们知道了，连接其实并不是所谓的有一根电线连起两个设备，而是两方确认了一下对方的存在后，自己在本地记录的状态。那么下面可以讨论一下以前迷惑重重的概念了。4.为什么服务器都有连接数量的限制？这里只做讨论。我认为是有两点：物理带宽的限制，决定了一个时间段内发起连接的数据包不会超过某个数，造成了设备的链接数量的限制。维持连接需要分配内存等资源，设备的资源有限，决定了一定有个最大连接数的极限。5.待续 通过连接往外延伸的话题不少，先到此为止吧，有时间再补。

这句话是错误的。正确的是在TCP/IP协议中，TCP提供可靠的面向连接服务，UDP提供简单的无连接服务，而电子邮件、文件传送协议等应用层服务是分别建立在TCP协议、UDP协议、TCP或UDP协议之上的。多个不同网络间实现信息传输的协议簇。TCP/IP协议不仅仅指的是TCP 和IP两个协议，而是指一个由FTP、SMTP、TCP、UDP、IP等协议构成的协议簇， 只是因为在TCP/IP协议中TCP协议和IP协议最具代表性。扩展资料：TCP/IP协议在一定程度上参考了OSI的体系结构。OSI模型共有七层，从下到上分别是物理层、数据链路层、网络层、运输层、会话层、表示层和应用层。但是这显然是有些复杂的，所以在TCP/IP协议中，它们被简化为了四个层次。因为数据链路层和物理层的内容相差不多，所以在TCP/IP协议中它们被归并在网络接口层一个层次里。只有四层体系结构的TCP/IP协议，与有七层体系结构的OSI相比要简单了不少，也正是这样，TCP/IP协议在实际的应用中效率更高，成本更低。
错误，说反了，在TCP/IP协议中,UDP提供简单的无连接服务,TCP提供可靠的面向连接的服务

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的基础！