tcp建立连接占用哪些资源(TCP建立连接时状态还有哪些异常)

在介绍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个字节。

TCP/IP协议是一个协议集合，HTTP协议，IP协议，TCP协议，DNS协议等都属于TCP/IP协议。 TCP/IP协议是为了保证全球亿万台计算机能准确、无误的通信。TCP/IP中分层是很重要的概念，每层完成不同的功能。分为应用层，传输层，网络层，数据链路层。分层的目的是为了层级之间的功能相对队里，互不影响。TCP/IP通信数据流HTTP是基于TCP/IP协议的应用层协议，它不涉及数据包的传输，主要规定了客户端和服务器端的通信协议，默认端口是80IP协议的作用是将各种数据包准确无误的传递给对方，其中重要的条件是IP地址和MAC地址。由于IP地址是稀有资源，不可能每个人都有一个IP地址，所以我们通常的IP地址都是路由器给我们生成的IP地址，路由器里面会记录我们的MAC地址，而MAC地址是唯一的。IP实现的两个基本功能：寻址和分段寻址功能就是原地址和目标地址之间建立连接，需要使用ARP协议（Address Resolution Protocol），IP协议就是找到一条连接两台电脑的路径，从而完成数据的交互。地址解析协议，ARP协议，是根据IP地址获取物理地址的一个TCP/IP协议。IP间的通信依赖MAC地址。在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标，这时就会采用ARP协议，根据通讯放的IP地址就可以反查出对应的MAC地址，从而进行精确的定位，完成寻址的功能。分段功能是为了适应不同网络对包的要求，对数据进行重新组装。TCP协议就是将数据包安全的给对方，IP协议是找到对方的详细地址，分工不同，互不冲突。TCP属于传输层，提供可靠的字节流服务。字节流类似于数据切割，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。可靠的传输服务是指，能够把数据准确可靠的传给对方。TCP协议为了更容易的传输大数据才将数据进行分割，而且TCP协议能够确认数据最终是否送达对方。为了确保信息准确无误的送达，TCP采用了三次握手策略（three-way-handshaking）。TCP建立连接时需要三次握手，在关闭连接时还需要四次握手。 这部分占用了http请求过程的中大量时间，在高并发时，可以考虑优化这部分。和HTTP协议一样是处于应用层的服务，提供域名到IP地址之间的解析服务。1、可缓存：get请求能缓存，post请求不能；响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。2、get是获取资源，post用于传输实体主体。3、参数：get请求的参数在url里面，会被浏览器保存历史记录，post的请求数据在数据包里面，同时因为url只支持ASCII码，因此get的参数如果存在汉字就要先进性编码，post请求支持更多的编码类型且不对数据类型限制；post传输的数据比get的多；url的长度有限制，会影响get请求；4、安全的HTTP方法不会改变服务器状态，也就说是只读的。所以get是安全的，post不是安全的。5、幂等性：get是幂等的，post不是幂等的。6、XMLHttpRequest： 在使用XMLHttpRequest时，post请求发送时，浏览器会先发送header再发送Data；get请求header和data一起发送。XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。200 OK，表示从客户端发来的请求在服务器端被正确处理。204 No content，表示请求成功，但是想要报文不包含实体的主体部分。206 Partial Content ，进行范围请求。301 moved permanently 永久性重定向，表示自愿一杯分配了新的URL。302 found 临时性重定向，表示自愿临时被分配了新的URL。303 see other 表示资源存在着另一个URL，应使用GET方法获取资源。和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。304 not modified 表示服务器允许访问资源，但因发生请求未满足条件的情况。307 temporary redirect，临时重定向，和302含义相同。但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。400 bad request 请求报文存在语法错误401 unauthorized 表示没有权限403 forbidden 表示对请求资源的访问被服务器拒绝404 not found 表示在服务器上没有找到请求的资源500 internal sever error 表示服务器端在执行请求时错误503 service unavailable 表明服务器暂时处于超负载或正在停机维护，无法处理请求HTTPS是HTTP建立在SSL/TLS安全协议上的。在IOS中，客户端本地会存有CA证书，在HTTPS请求时，会首先向服务器获取公钥，获得公钥后会使用本地的CA证书验证公钥的正确性，然后通过正确的公钥加密信息发送给服务器，服务器会使用私钥解密信息。SSL/TSL握手阶段分为五步：HTTP和HTTPS的对比：HTTP：无状态，协议对客户端没有状态存储；无连接，每次请求都会和服务器重新建立连接；基于请求和响应，由客户端发起，服务端响应；简单快速，灵活；使用明文，请求和响应不会对通信方进行确认，无法保证数据的完整性。 HTTPS:内容加密，采用混合加密技术，中间者无法直接查看明文内容；验证身份，通过证书认真客户端访问的是自己的服务器；保护数据完整性，放置传输的内容被中间人冒充或篡改。

需要。 TCP协议中有长连接和短连接之分。短连接在数据包发送完成后就会自己断开，长连接在发包完毕后，会在一定的时间内保持连接，即我们通常所说的Keepalive（存活定时器）功能。www.2cto.com 默认的Keepalive超时需要7,200,000 milliseconds，即2小时，探测次数为5次。它的功效和用户自己实现的心跳机制是一样的。开启Keepalive功能需要消耗额外的宽带和流量，尽管这微不足道，但在按流量计费的环境下增加了费用，另一方面，Keepalive设置不合理时可能会因为短暂的网络波动而断开健康的TCP连接。

整理自 CSDN 公众号1. 客户端TCP 三次握手的开始是客户端发起 SYN，如果服务端没有及时回复，那么会重传，重传的间隔和次数是可控的，默认是五次，第一次间隔 1 秒，第二次 2 秒，第三次 4 秒，第四次 8 秒，第五次16 秒，最终超时时间是 63 秒，因此在优化时可以修改重传次数和间隔，以尽快把错误暴露给应用程序。2. 服务端的半连接队列优化服务端在第一次返回 SYN + ACK 时，就会把这次请求维护进一个半连接队列，这个队列用来维护尚未完成的握手信息（相对于全连接），如果这个队列溢出了，服务端就无法继续接受新的请求了，这也是 SYN Flood 攻击的点。通过一个命令 netstat -s 可以得到累计的、由于半连接队列已满引发的失败次数，隔几秒执行一次就可以知道这个次数是否有上升的趋势以及分析是否正常。这种 SYN Flood 攻击之所以成立，是因为维护这个半连接队列一定要分配一定的内存资源，那么应对的方式之一 syncookies 就是如何不分配资源的前提下，可以确认是一次有效的连接并 establish。syncookies 的工作原理是，服务器使用一种算法，计算出一个哈希值，它包含了客户端发来请求的部分信息，再将这个哈希值和 SYN+ACK 一起返回给客户端，客户端也经过一些运算，再返回给服务端，那么服务端根据这个返回值和之前的计算值比较，如果合法，就可以建立有效连接，从而不会占据半连接队列的内存。应对 SYN 攻击时，只需将 syncookies 的参数值调为 1（半连接队列溢出时启用），即可。相当的，可以增大半连接队列，但是要和 accept 的队列同时增大才有效，（否则会导致 accept 队列溢出同样丢失 TCP 连接）此时，对于客户端来说已经是 established 状态，但是还要再返回给服务端一个 ACK，服务端收到后，服务端才是 established 状态并开始传数据，如果网络不稳定，同样的，服务端会重发 SYN+ACK，当网络不稳定时，应该增加服务端重发 SYN+ACK 的次数。3. 服务端的 accept 队列优化当连接已经建立、应用程序尚未调用时，TCP 连接会被保存在一个 accept 队列中，如果进程未能及时调用，就会导致 accept 队列溢出，溢出部分连接将被默认丢弃。对此可以做的是，选择向客户端发送 RST 报文，告知关闭这个连接，丢弃握手过程。打开这一功能需要将 tcp_abort_on_overflow 参数设置为 1。如果想让客户端了解是由于 accept 队列溢出造成连接失败可以这样做。当 tcp_abort_on_overflow 参数设置为 0 时，则如果 accept 队列溢出，就会丢弃客户端传来的 ACK（用于最后一次握手）。应对高并发流量时，更好的选择是 tcp_abort_on_overflow 参数设置为 0，这样对于客户端它的状态仍然是 established，客户端会定时发送带有 ack 报文的发送数据请求，一旦服务端的 accept 队列有空位，那么连接仍有可能建立成功。所以只有很确定在一段时间内 accept 都是将溢出的状态，才推荐 tcp_abort_on_overflow 参数设置为 1。同样的，可以调整 accept 队列长度，也可以查看累计的由于溢出导致丢失的连接总数，来判断趋势。在 Linux 3.7 内核版本之后，提供了 TCP Fast Open 功能，这个功能如此生效：初次建立 TCP 连接时，客户端在第一个 SYN 包中传入一个请求 cookie，表明打开 fast open 功能，服务端对应生成一个 cookie 给客户端，除此之外，三次握手没有不同，但是，在 cookie 没有过期之前，下一次再连接的时候，客户端发送带有 cookie 的 SYN 包，服务端校验了 cookie 有效以后，就可以开始传输数据了，从而节约了一个往返的时间消耗。TCP Fast Open 功能需要服务端和客户端同时打开才能生效。（备注一个之前看到差点忘了的知识点。当主动方收到被动方的 FIN 报文后，内核会回复 ACK 报文给被动方，同时主动方的连接状态由 FIN_WAIT2 变为 TIME_WAIT，在 Linux 系统下大约等待 1 分钟后，TIME_WAIT 状态的连接才会彻底关闭。1. 主动方的优化关闭的方式有两种 RST 和 FIN，RST 是暴力关闭连接的方式，安全关闭连接则必须四次挥手。FIN 报文关闭则可以使用 close 和 shutdown 两种函数来实现。close 相对来说是“不优雅”的，调用 close 的一方的连接叫做「孤儿连接」，会同时关闭读和写，而 shutdown 可以控制是读还是写。关闭读的时候，会丢弃接收缓冲区里的所有数据，如果后续再接受到数据，也会悄悄丢弃，并发送 ACK，对方不会知道被丢弃了。关闭写的时候，会把发送缓冲区的数据全部发送并发送 FIN。（1）FIN_WAIT1 的优化主动方发送 FIN 以后，进入 FIN_WAIT1 状态，如果迟迟没收到 ACK，会定时重发 FIN，重发次数由 tcp_orphan_retries 参数控制，默认为 8 次，如果处于 FIN_WAIT1 状态的连接过多，应该考虑降低次数，重发次数超过参数时，连接会被直接关闭。如果遇到恶意攻击，可能无法发送出 FIN，因为 TCP 按顺序发送所有包， FIN 也不能绕过，另外如果对方的接收窗口已经满了，发送方也无法再发送数据。此时应该做的是调整 tcp_max_orphans 参数，它定义了「孤儿连接」的最大数量，当系统中的孤儿连接超过参数值，新增的孤儿连接不会再处于 FIN_WAIT1 状态，而是会被 RST 报文直接关闭。（只会影响 CLOSE 函数关闭的连接，不会影响 shutdown 关闭的，不会影响还有读或写的可能）（2）FIN_WAIT2 的优化主动方收到 ACK 后，会处于 FIN_WAIT2，因为被动方还可能有数据发送，如果是 shutdown 关闭，那它也可能还会发送数据，但是对于 close 关闭的连接，无法再发送和接收数据，保持在 FIN_WAIT2 的状态已经没有太大意义，tcp_fin_timeout 控制了这个状态下连接的持续时长，默认值是 60 秒。这个时间和 TIME_WAIT 状态时长是一致的。（3）TIME_WAIT 的优化TIME_WAIT 和 FIN_WAIT2 的时间是一致的，都是 2MSL，1MSL 表示一个报文在网络中存活的最长时间（报文每经过一次路由器的转发，IP 头部的 TTL 字段就会减 1，减到 0 时报文就被丢弃，这就限制了报文的最长存活时间），那么为什么是等待 2MSL 呢，其实就是允许报文至少丢失一次、再发送一次，这样第一个丢失了，等待的时间里第二个 ACK 还会到达，为什么不是 4MSL 以上呢，这是一个概率的问题，如果一个网络丢包率达到 1%，那么连续两次丢包的概率是万分之一，不必为了这种概率增加等待的时长。TIME_WAIT 有存在的意义，但是太多保持在这种状态的连接会占用双方资源，占据客户端的端口资源和服务端的系统资源。Linux 提供了 tcp_max_tw_buckets 参数，当 TIME_WAIT 的连接数量超过该参数时，新关闭的连接就不再经历 TIME_WAIT 而直接关闭。这个参数的设定应该取一个平衡点，即既不会太少导致高并发时产生连接间数据错乱的问题，也不会太多而导致耗尽端口和线程资源。对于用户端来讲，还可以启用 tcp_tw_reuse 参数来复用处于 TIME_WAIT 状态的连接（来节约接口资源。）这个参数有几个前提，一个是只有客户端可以打开，一个是 TIME_WAIT 状态也要保持 1 秒，另一个是要同步打开时间戳功能，报文带上时间戳就可以避免没有了 2MSL 时长以后的混乱情况，时间戳过期的报文就会被丢掉。另外对于 TIME_WAIT，还可以调整 socket 选项，来达到调用 close 关闭连接时跳过四次挥手直接关闭的效果，但不推荐。2. 被动方的优化首先，被动方收到 FIN 时，会自动回复 ACK，接着等待应用程序调用 close/shutdown 来结束连接，再发送 FIN。如果系统中同时查看到多个连接处于 CLOSE_WAIT 状态，则需要排查是否是应用程序出了故障。然后，当被动方也发送了 FIN 以后，还需要等待主动方回复一个 ACK，如果迟迟没收到，也会重发 FIN，重发次数也是 tcp_orphan_retries 参数控制，这点和主动方的优化一致，可以调整次数。（需确认被动方是否有 tcp_max_orphans 参数）3. 如果双方同时关闭？1.ACK 延迟目前在 TCP 中每传输一个报文都要求接收方进行确认，大量短而频繁的确认报文给网络带来了很多开销。因此采取了延迟 ACK 策略来减少 ACK 的数量，就是接收方收到一个报文以后，不会立即发送 ACK，而是等待 1~200ms，这期间若有回送数据报文就捎带确认，但收到两个连续数据报文或者等待超时则发送一个独立确认。有效减少了 ACK 的数量，改善了 TCP 的整体性能。2. 滑动窗口接收方的接收缓冲区不是不变的，接收到新的会变小，应用程序取出后又会变大，因此接收方会把自己当前的接收窗口大小放在 TCP 头告知发送方，如果不考虑拥塞控制，发送方的窗口大小「约等于」接收方的窗口大小。对于这一点，可以把 tcp_window_scaling 配置设为 1（默认打开）来扩大 TCP 通告窗口至 1G 大小。要使用这一选项，需要主动方在 SYN 中先告知，被动方在 SYN 中再反馈。但是缓冲区并非越大越好，还要考虑网络吞吐的能力。如果缓冲区与网络传输能力匹配，那么缓冲区的利用率就达到了最大化。3. 调整缓冲区大小这里需要说一个概念，就是带宽时延积，它决定网络中飞行报文的大小，它的计算方式：（1）发送缓冲区的调整发送缓冲区是自行调节的，当发送方发送的数据被确认后，并且没有新的数据要发送，就会把发送缓冲区的内存释放掉。接收缓冲区要复杂一些：上面三个数字单位都是字节，它们分别表示：（2）接收缓冲区的调整接收缓冲区可以根据系统空闲内存的大小来调节接收窗口：（3）内存的判断那么如何判断内存紧张或充分呢？上面三个数字单位不是字节，而是「页面大小」，1 页表示 4KB，它们分别表示：在实际的场景中，TCP 缓冲区最小值保持默认 4K 即可，来提高并发处理能力；最大值则尽可能靠近带宽时延积，来最大化网络效率。总结以上：为了提高并发能力、提高网络效率，我们要充分利用网络能力和自己的内存。网络这方面就是将缓冲区大小的极值尽可能靠近带宽时延积，而同时对缓冲区的自动调节需要结合内存来判断，这个 TCP 内存的判断是通过系统内存计算出来的几个值来划分的，在不同区间会对分配给缓冲区的内存大小进行调整。以上就是 TCP 在不同阶段的优化策略和思路，有关拥塞控制和流量控制之后再补一篇笔记。

TCP/IP是计算机网络中的两个常用协议，一般无需用户自行设置。 TCP/IP协议并不完全符合OSI的七层参考模型。传统的开放式系统互连参考模型，是一种通信协议的7层抽象的参考模型,其中每一层执行某一特定任务。该模型的目的是使各种硬件在相同的层次上相互通信。这7层是:物理层、数据链路层、网路层、传输层、话路层、表示层和应用层。而TCP/IP通讯协议采用了4层的层级结构，每一层都呼叫它的下一层所提供的网络来完成自己的需求。这4层分别为：应用层：应用程序间沟通的层，如简单电子邮件传输（SMTP）、文件传输协议（FTP）、网络远程访问协议（Telnet）等。传输层：在此层中，它提供了节点间的数据传送服务，如传输控制协议（TCP）、用户数据报协议（UDP）等，TCP和UDP给数据包加入传输数据并把它传输到下一层中，这一层负责传送数据，并且确定数据已被送达并接收。互连网络层：负责提供基本的数据封包传送功能，让每一块数据包都能够到达目的主机（但不检查是否被正确接收），如网际协议（IP）。网络接口层：对实际的网络媒体的管理，定义如何使用实际网络（如Ethernet、SerialLine等）来传送数据NTP:做网络时钟（时间来源于互联网，本地不用RTC）RTP、RTSP:视频监控常用的协议SNMP:简单网络管理协议（集中式管理）目的地址与源地址都是MAC（物理地址）；数据字段长度： 数据的类型（比如0x0800：表示帧里面的“数据”字段是一个IP包）数据：这里面存放具体的数据包。IP协议层：IP协议主要目的是为数据的输入、输出网络提供基本算法，为高层协议提供无连接的传送服务。IP协议层的功能：数据传送、寻址、路由选择、数据报文的分段。TCP协议：TCP协议是重要的传输层协议，它的目的是为网络上的各节点提供可靠的数据交换。它提供数据端口编号的译码，以识别主机的应用程序，完成数据的可靠传送。UDP协议:传送层协议，它是无连接不可靠的传送。当接收数据时它并不向发送方提供确认信息，它不提供输入包的顺序，如果出现丢失包或重份包的情况，也不会向发送方发出差错报文，它的执行速度比TCP快，执行时具有较低的开销。在实际的网络设计中，服务器必须要实现1对多的功能模型；这里就可分为两种服务器：循环服务器与并发服务器。上面介绍的TCP、UDP通信模型都是循环服务器，TCP的循环服务器与UDP的循环服务器又不同；TCP循环服务器一次只能处理一个客户端的请求。所以一个客户端占住服务器不放，其他的客户端就没法访问服务器，所以在服务器端TCP服务器很少使用循环模式。但是UDP的循环服务器与TCP循环服务器不一样，因为UDP不需要建立连接（TCP建立连接后完全占用服务器），所以UDP的循环服务器直接可以服务多个客户端。并发服务器：TCP需要使用并发服务器模型才能服务多个客户端。 并发服务器的设计思路是每个客户端的请求并不由服务器直接处理，而是由服务器创建一个子进程来处理。