TCP选项TCP_DEFER_ACCEPT
linux tcp_defer_accept用法
linux tcp_defer_accept用法在Linux中的TCP_DEFER_ACCEPT选项可以用于延迟接受TCP连接。
通过该选项，可以在内核中等待一段时间来接受连接，这样可以确保服务器已准备好处理连接。
TCP_DEFER_ACCEPT选项可以通过setsockopt函数来设置，具体使用方法如下：```cint optval = 1;setsockopt(sockfd, IPPROTO_TCP, TCP_DEFER_ACCEPT,&optval, sizeof(optval));```在上述代码中，sockfd是一个已经创建好的socket文件描述符，optval是一个整数变量，用于表示是否启用TCP_DEFER_ACCEPT选项。
将optval设置为1表示启用，设置为0表示禁用。
通过启用TCP_DEFER_ACCEPT选项，可以在accept系统调用中等待一段时间来接受连接。
在等待期间，内核会进行一些必要的处理，如发送SYN-ACK应答等。
等待时间的长短可以通过tcp_defer_accept_interval内核参数来调整。
系统默认的等待时间是3秒。
设置TCP_DEFER_ACCEPT选项可以在一定程度上减少由于即时接受连接而导致的资源浪费，提高服务器的性能。
特别适用于一些需要进行比较复杂的初始化操作的服务器应用程序，如使用SSL/TLS进行连接加密的Web服务器。
需要注意的是，TCP_DEFER_ACCEPT只适用于TCP连接，对于其他类型的套接字如UDP不起作用。
此外，启用TCP_DEFER_ACCEPT选项并不会改变客户端连接的行为，客户端仍会在其自身设定的超时时间内等待或进行重试。
TCP标志位详解及tcp拦截配置
TCP标志位详解及tcp拦截配置TCP标志位URG：此标志表示TCP包的紧急指针域（后面马上就要说到）有效，用来保证TCP 连接不被中断，并且督促中间层设备要尽快处理这些数据；ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中；有两个取值：0和1，为1的时候表示应答域有效，反之为0；PSH：这个标志位表示Push操作。
所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序，而不是在缓冲区中排队；RST：这个标志表示连接复位请求。
用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包；SYN：表示同步序号，用来建立连接。
SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1，ACK=0；连接被相应的时候，SYN=1，ACK= 1；这个标志的数据包经常被用来进行端口扫描。
扫描者发送一个只有SYN的数据包，如果对方主机响应了一个数据包回来，就表明这台主机存在这个端口；但是由于这种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全的主机将会强制要求一个连接严格的进行TCP的三次握手；FIN：表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志位的TCP数据包后，连接将被断开。
这个标志的数据包也经常被用于进行端口扫描。
当一个FIN标志的TCP数据包发送到一台计算机的特定端口，如果这台计算机响应了这个数据，并且反馈回来一个RST标志的TCP包，就表明这台计算机上没有打开这个端口，但是这台计算机是存在的；如果这台计算机没有反馈回来任何数据包，这就表明，这台被扫描的计算机存在这个端口。
*SYN：同步标志同步序列编号(Synchronize Sequence Numbers)栏有效。
该标志仅在三次握手建立TCP连接时有效。
它提示TCP连接的服务端检查序列编号，该序列编号为TCP 连接初始端(一般是客户端)的初始序列编号。
TCP协议中的TCP_NODELAY与TCP_CORK选项：使用与设置建议(四)
TCP协议中的TCP_NODELAY与TCP_CORK选项：使用与设置建议引言：在网络通信中，传输控制协议（TCP）是一种广泛使用的协议。
为了提高网络性能和延迟，TCP提供了一些选项供开发者使用，其中TCP_NODELAY和TCP_CORK选项尤为重要。
本文旨在探讨这两个选项的用途、设置建议以及使用中的注意事项。
一、TCP_NODELAY选项TCP_NODELAY选项可用于禁用TCP的Nagle算法。
Nagle算法是一种优化TCP数据传输的算法，它通过减少发送小封包的数量来提高网络吞吐量。
然而，对于交互性较强的应用（如实时视频和游戏），发送小封包会造成较大的延迟。
因此，可以通过设置TCP_NODELAY选项来禁用Nagle算法，实现更低的延迟。
设置TCP_NODELAY选项的方法取决于使用的编程语言和操作系统。
一般来说，可以通过设置TCP套接字的选项参数来开启或关闭TCP_NODELAY。
在C语言中，可以使用setsockopt函数来进行设置。
然而，需要注意的是，禁用Nagle算法可能会导致网络拥塞以及发送大量的小封包。
因此，应慎重使用TCP_NODELAY选项，并确保在合适的场景中使用。
在传输大量数据的应用中，禁用Nagle算法可以提高吞吐量，在实时性要求较高的应用中，禁用Nagle算法可以降低延迟。
二、TCP_CORK选项TCP_CORK选项可以用于缓存发送的TCP数据，直到达到一定的条件后再一次性发送。
这个选项常用于减少小封包的发送次数，提高网络性能和延迟。
当开启TCP_CORK选项后，TCP套接字会在接收到的数据达到一定的条件后，才开始发送。
同样，设置TCP_CORK选项的方法也因编程语言和操作系统而异。
在C语言中，也可以使用setsockopt函数来进行设置。
需要注意的是，应谨慎选择该选项的使用场景。
对于交互性较强的应用，如实时游戏和视频会议，如果将数据长时间缓存而不及时发送，会增加用户的感知延迟。
几种TCP连接中出现RST的情况(比较详细)
几种TCP连接中出现RST的情况17人收藏此文章, 发表于1个月前(2013-05-04 11:40) , 已有314次阅读，共个评论目录：[ ]••••••应该没有人会质疑，现在是一个网络时代了。
应该不少程序员在编程中需要考虑多机、局域网、广域网的各种问题。
所以网络知识也是避免不了学习的。
而且笔者一直觉得TCP/IP网络知识在一个程序员知识体系中必需占有一席之地的。
在TCP协议中RST表示复位，用来异常的关闭连接，在TCP的设计中它是不可或缺的。
发送RST包关闭连接时，不必等缓冲区的包都发出去，直接就丢弃缓存区的包发送RST包。
而接收端收到RST包后，也不必发送ACK包来确认。
其实在网络编程过程中，各种RST错误其实是比较难排查和找到原因的。
下面我列出几种会出现RST的情况。
1 端口未打开服务器程序端口未打开而客户端来连接。
这种情况是最为常见和好理解的一种了。
去telnet一个未打开的TCP的端口可能会出现这种错误。
这个和操作系统的实现有关。
在某些情况下，操作系统也会完全不理会这些发到未打开端口请求。
比如在下面这种情况下，主机241向主机114发送一个SYN请求，表示想要连接主机114的40000端口，但是主机114上根本没有打开40000这个端口，于是就向主机241发送了一个RST。
这种情况很常见。
特别是服务器程序core dump 之后重启之前连续出现RST的情况会经常发生。
当然在某些操作系统的主机上，未必是这样的表现。
比如向一台WINDOWS7的主机发送一个连接不存在的端口的请求，这台主机就不会回应。
2 请求超时曾经遇到过这样一个情况:一个客户端连接服务器，connect返回-1并且error=EI NPROGRESS。
直接telnet发现网络连接没有问题。
ping没有出现丢包。
用抓包工具查看，客户端是在收到服务器发出的SYN之后就莫名其妙的发送了RST。
比如像下面这样：有89、27两台主机。
linux tcp参数
linux tcp参数Linux TCP参数是指在Linux系统中用于控制TCP协议的一系列参数。
这些参数可以影响TCP连接的性能、稳定性和安全性。
在本文中，我们将介绍一些常见的Linux TCP参数及其作用。
1. tcp_syncookiestcp_syncookies是一种防止SYN洪水攻击的机制。
当服务器收到大量的SYN请求时，它会启用tcp_syncookies机制，将一些连接信息存储在cookie中，以便在后续的连接请求中进行验证。
这样可以防止服务器被SYN洪水攻击所瘫痪。
2. tcp_fin_timeouttcp_fin_timeout是指在TCP连接关闭后，等待多长时间才能释放连接资源。
默认情况下，它是60秒。
如果你的应用程序需要频繁地打开和关闭连接，可以将tcp_fin_timeout设置为较小的值，以便更快地释放连接资源。
3. tcp_keepalive_timetcp_keepalive_time是指在TCP连接空闲时，发送keepalive消息的时间间隔。
默认情况下，它是7200秒。
如果你的应用程序需要保持长时间的连接，可以将tcp_keepalive_time设置为较小的值，以便更快地检测到连接是否已经断开。
4. tcp_max_syn_backlogtcp_max_syn_backlog是指在SYN队列中允许的最大连接数。
默认情况下，它是128。
如果你的服务器需要处理大量的连接请求，可以将tcp_max_syn_backlog设置为较大的值，以便更好地处理连接请求。
5. tcp_tw_reusetcp_tw_reuse是指在TIME_WAIT状态下，是否允许重用端口。
默认情况下，它是关闭的。
如果你的服务器需要频繁地打开和关闭连接，可以将tcp_tw_reuse设置为开启，以便更好地利用端口资源。
Linux TCP参数可以帮助你优化TCP连接的性能、稳定性和安全性。
通过了解和调整这些参数，你可以更好地控制你的服务器和应用程序。
c语言 tcpip 阻塞非阻塞用法
在C语言中，TCP/IP套接字可以以阻塞（blocking）或非阻塞（non-blocking）模式运行。
这两种模式决定了套接字在进行网络通信时的行为。
1. 阻塞模式：在阻塞模式下，当套接字执行输入/输出操作时，程序会一直等待，直到操作完成或出现错误。
阻塞模式是默认的套接字行为。
例如，在阻塞模式下，如果调用recv()函数接收数据，但没有数据可供接收，程序将一直等待，直到有数据可用为止。
2. 非阻塞模式：在非阻塞模式下，当套接字执行输入/输出操作时，程序不会等待操作完成，而是立即返回。
如果操作无法立即完成，则返回一个错误代码（例如EWOULDBLOCK或EAGAIN），表示操作当前不可用。
程序可以通过轮询套接字状态或使用回调函数等方式来检查操作是否完成。
非阻塞模式可以让程序在等待网络操作期间能够处理其他任务，提高了程序的响应性能。
下面是一个简单的示例，演示了如何设置和使用阻塞和非阻塞套接字：```c#include <stdio.h>#include <sys/socket.h>#include <fcntl.h>int main() {int sockfd;// 创建套接字sockfd = socket(AF_INET, SOCK_STREAM, 0);// 设置为非阻塞模式int flags = fcntl(sockfd, F_GETFL, 0);fcntl(sockfd, F_SETFL, flags | O_NONBLOCK);// 在非阻塞模式下进行操作int ret = connect(sockfd, (struct sockaddr*)&server_addr, sizeof(server_addr)); if (ret == -1) {// 连接操作当前不可用if (errno == EINPROGRESS) {// 连接正在进行中，可以继续处理其他任务} else {// 发生错误perror("connect");return 1;}}// 恢复为阻塞模式fcntl(sockfd, F_SETFL, flags);// 在阻塞模式下进行操作ret = send(sockfd, buffer, sizeof(buffer), 0);if (ret == -1) {// 发生错误perror("send");return 1;}close(sockfd);return 0;}```在上面的示例中，首先创建了一个套接字，并将其设置为非阻塞模式。
nginx学习总结
Nginx学习总结Nginx概述及注意事项✧nginx是一个高性能的 HTTP 和反向代理服务器，也是一个 IMAP/POP3/SMTP 代理服务器。
✧目前Nginx使用简单的轮巡（polling）算法来实现负载均衡，所以无法做基本链接计数的负载均衡。
✧目前官方 Nginx 并不支持 Windows，您只能在包括 Linux、UNIX、BSD 系统下安装和使用；✧Nginx 本身只是一个 HTTP 和反向代理服务器，它无法像 Apache 一样通过安装各种模块来支持不同的页面脚本，例如 PHP、CGI 等；✧Nginx 支持简单的负载均衡和容错；✧支持作为基本 HTTP 服务器的功能，例如日志、压缩、Byte ranges、Chunked responses、SSL、虚拟主机等等，应有尽有。
Nginx优势✧在高连接并发的情况下，Nginx是Apache服务器不错的替代品：Nginx在美国是做虚拟主机生意的老板们经常选择的软件平台之一。
能够支持高达 50,000 个并发连接数的响应，感谢Nginx为我们选择了epoll and kqueue作为开发模型。
✧Nginx作为负载均衡服务器：Nginx 既可以在内部直接支持Rails 和PHP 程序对外进行服务，也可以支持作为HTTP代理服务器对外进行服务。
Nginx采用C 进行编写，不论是系统资源开销还是CPU使用效率都比 Perlbal 要好很多。
✧作为邮件代理服务器：Nginx 同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器），Last. fm 描述了成功并且美妙的使用经验。
✧Nginx 是一个安装非常的简单，配置文件非常简洁（还能够支持perl语法），Bugs非常少的服务器：Nginx 启动特别容易，并且几乎可以做到7*24不间断运行，即使运行数个月也不需要重新启动。
Nginx等单线程服务器设计原理与性能优势Nginx是以单线程为基础的，nginx通过异步IO来解决主线程阻塞的问题。
iptables的状态检测机制(TCPUDPICMP状态详解)
iptables的状态检测机制（TCPUDPICMP状态详解）iptables是一个用于Linux操作系统的防火墙工具，用于管理网络数据包的过滤和转发。
它可以监测和控制网络流量，确保网络的安全性和可靠性。
在iptables中，有三种状态检测机制，即TCP状态检测、UDP 状态检测和ICMP状态检测。
本文将详细介绍这三种机制。
1.TCP状态检测：TCP（传输控制协议）是一种面向连接的、可靠的传输协议，通过三次握手建立和维持连接。
在iptables中，我们可以使用TCP状态检测来监测TCP连接的状态并控制流量。
常用的TCP状态检测有以下几种：- NEW：检测新建立的TCP连接。
当iptables检测到一个新的TCP连接时，它会按照我们预先定义的规则进行处理。
- ESTABLISHED：检测已建立的TCP连接。
当iptables检测到一个已建立的TCP连接时，它会根据我们的规则允许或拒绝数据包的传输。
-RELATED：检测与已建立的TCP连接相关的连接。
比如FTP数据连接就是建立在一个FTP控制连接之上的，这时候可以使用RELATED状态检测来检测与FTP控制连接相关的数据连接。
- INVALID：检测无效的TCP连接。
当iptables检测到一个无效的TCP连接时，它会拒绝该连接并记录日志。
通过对TCP连接状态的检测，我们可以根据需要采取相应的安全措施和控制措施，确保网络的安全性和可靠性。
2.UDP状态检测：UDP（用户数据报协议）是一种无连接的、不可靠的传输协议，数据包之间没有建立连接的过程。
在iptables中，我们可以使用UDP状态检测来监测UDP连接的状态并进行相应的处理。
常用的UDP状态检测有以下几种：- NEW：检测新收到的UDP数据包。
当iptables检测到一个新的UDP数据包时，它会按照我们预先定义的规则进行处理。
- ESTABLISHED：检测已建立的UDP连接。
当iptables检测到一个已建立的UDP连接时，它会根据我们的规则允许或拒绝数据包的传输。
tcpserver和tcpclient的使用方法
tcpserver和tcpclient的使用方法TCP（Transmission Control Protocol）是一种传输层协议，提供可靠的连接服务，被广泛应用于各种网络通信中。
为了实现TCP通信，我们需要使用TCP服务器（TCP server）和TCP 客户端（TCP client）。
下面将分别介绍TCP服务器和TCP客户端的使用方法。
一、TCP服务器（TCP server）的使用方法：TCP服务器用于接收并处理来自TCP客户端的连接请求，并与客户端建立可靠的一对一连接，实现双向通信。
以下是TCP服务器的使用方法：1. 创建TCP服务器：- 使用socket库的socket()函数创建套接字，指定套接字类型为AF_INET（IPv4）和SOCK_STREAM（TCP）。
- 使用bind()函数将套接字与指定的IP地址和端口号绑定。
- 使用listen()函数开始监听连接请求。
2. 接受连接请求：- 使用accept()函数接受客户端的连接请求，返回一个新的套接字，用于与客户端通信。
3. 通信：- 使用新的套接字与客户端进行通信。
可以使用send()函数向客户端发送数据，使用recv()函数接收客户端发送的数据。
4. 关闭连接：- 使用close()函数关闭与客户端的连接。
这样，TCP服务器就可以接收多个客户端的连接请求，并与客户端分别建立连接进行通信。
二、TCP客户端（TCP client）的使用方法：TCP客户端用于主动发起连接到TCP服务器，并与服务器建立可靠的一对一连接，实现双向通信。
以下是TCP客户端的使用方法：1. 创建TCP客户端：- 使用socket库的socket()函数创建套接字，指定套接字类型为AF_INET（IPv4）和SOCK_STREAM（TCP）。
2. 建立连接：- 使用connect()函数连接到指定的服务器IP地址和端口号。
3. 通信：- 使用已连接的套接字与服务器进行通信。
如何进行TCP参数参数调优
如何进行TCP参数参数调优
为了提高TCP协议的性能和稳定性，我们可以进行一些调优：
TCP窗口大小：TCP窗口大小控制数据包在发送端和接收端之间的传
输速度，通过增加TCP窗口大小可以提高网络吞吐量。
可以使用
tcp_window_scaling参数来启用窗口缩放，并使用tcp_rmem和tcp_wmem
参数设置接收和发送缓冲区的大小。
延迟确认：TCP协议默认使用延迟确认，即等待一段时间再发送确认
数据包，以减少网络流量。
可以使用tcp_sack参数来启用选择性确认，
并使用tcp_ack_delay参数调整延迟确认时间，以提高TCP协议的响应速度。
慢启动：TCP协议使用慢启动算法来控制拥塞窗口大小，以避免网络
拥塞。
可以使用tcp_slow_start_after_idle参数来调整慢启动算法的启
动时间，并使用tcp_congestion_control参数选择合适的拥塞控制算法。
超时重传：TCP协议使用超时重传机制来处理丢失的数据包，以保证
数据可靠性。
可以使用tcp_retries1和tcp_retries2参数来调整重传次
数和超时时间，以提高TCP协议的可靠性。
MTU大小：MTU是网络中最大传输单元的缩写，控制TCP数据包的大小。
可以使用tcp_mtu_probing参数启用MTU探测，并使用tcp_mss参数
设置最大数据包大小，以提高网络传输效率。
iptables的状态检测机制（TCP、UDP、ICMP状态详解）
iptables的状态检测机制（TCP、UDP、ICMP状态详解）iptables 的状态检测机制的状态检测机制1.1.什么是状态检测什么是状态检测什么是状态检测每个网络连接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字对(socket pairs);协议类型、连接状态(TCP 协议)和超时时间等。
防火墙把这些信息叫作状态(stateful)，能够检测每个连接状态的防火墙叫作状态包过滤防火墙。
它除了能够完成简单包过滤防火墙的包过滤工作外，还在自己的内存中维护一个跟踪连接状态的表，比简单包过滤防火墙具有更大的安全性。
iptables 中的状态检测功能是由state 选项来实现的。
对这个选项，在iptables 的手册页中有以下描述：state这个模块能够跟踪分组的连接状态(即状态检测)。
--state state这里，state 是一个用逗号分割的列表，表示要匹配的连接状态。
有效的状态选项包括：INVAILD，表示分组对应的连接是未知的; ESTABLISHED，表示分组对应的连接已经进行了双向的分组传输，也就是说连接已经建立;NEW，表示这个分组需要发起一个连接，或者说，分组对应的连接在两个方向上都没有进行过分组传输;RELATED，表示分组要发起一个新的连接，但是这个连接和一个现有的连接有关，例如：FTP 的数据传输连接和控制连接之间就是RELATED 关系。
对于本地产生分组，在PREROUTING 或者OUTPUT 链中都可以对连接的状态进行跟踪。
在进行状态检测之前，需要重组分组的分片。
这就是为什么在iptables 中不再使用ipchains 的ip_always_defrag 开关。
UDP 和TCP 连接的状态表由/proc/net/ip_conntrack 进行维护。
稍后我们再介绍它的内容。
状态表能够保存的最大连接数保存在/proc/sys/net/ipv4/ip_conntrack_max 中。
深入理解TCP协议及其源代码
深⼊理解TCP协议及其源代码我选择的问题是：connect及bind、listen、accept背后的三次握⼿1.TCP建⽴连接的三次握⼿过程1. 第⼀次握⼿：客户端尝试连接服务器，向服务器发送syn(全称是同步序列编号)报⽂，syn=i，客户端进⼊SYN_SEND状态等待服务器确认2. 第⼆次握⼿：服务器接收客户端syn报⽂并确认（ack=i+1），同时向客户端发送⼀个新的SYN报⽂（syn=j），即SYN+ACK报⽂，此时服务器进⼊SYN_RECV状态3. 第三次握⼿：客户端收到服务器的SYN+ACK报⽂，向服务器发送确认报⽂ACK(ack=j+1），此报⽂发送并被客户端接收后，客户端和服务器进⼊ESTABLISHED状态，完成三次握⼿2.探究使⽤Linux Socket api建⽴TCP连接的过程从创建socket，到建⽴连接接收数据，最后关闭socket的过程如上图所⽰。
其中，和建⽴连接有关系的socket api主要是：connect、bind、listen和accept为了探究建⽴连接时发⽣了什么，和TCP三次握⼿有什么关系，我们使⽤之前实验所写的hello/hi程序，⽤gdb为这四个函数打上断点，并使⽤wireshark监视相应端⼝，抓取数据包当服务端运⾏bind，listen后，并没有捕获到任何数据包直到客户端运⾏connect后，才捕获到TCP三次握⼿发送的数据包，如下图所⽰可以通过抓取的数据包信息看到Socket是如何建⽴TCP连接的1. 由客户端（44434端⼝）发送SYN数据报给服务端（65432端⼝）,其中seq=0（这⾥和后⾯的seq，都是显⽰的相对seq，实际并不是0）2. 服务端返回SYN+ACK数据报给客户端，其中ack=1,seq=03. 客户端返回ACK数据报，其中ack=1通过这个实践可以推测，TCP的三次握⼿是在connect和accept之间完成的，bind和listen只是完成绑定和监听的功能3.从源码⾓度分析TCP三次握⼿的过程在上⼀个实验探究Socket底层是如何实现多态机制的时候，我们发现socket结构体中有⼀个名为ops的结构体指针，结构体中⼜通过函数指针绑定了具体的底层函数，完成了connect、accept的实现。
软考网络工程师知识点利用TCP.IP优化数据传输
软考网络工程师知识点：利用TCP/IP优化数据传输网络工程师的利用TCP/IP优化数据传输，减少网络流量当然是非常重要的优化举措之一，不过这种手段也仅仅是实现高性能网络数据传输领域的一个方面。
其他TCP选项也可能显着提供传输性能同时在某些条件下减少服务器的响应时间延迟。
下面就让我们来了解一些此类选项。
TCP_DEFER_ACCEPT我们首先考虑的第1个选项是TCP_DEFER_ACCEPT(这是Linux系统上的叫法，其他一些操作系统上也有同样的选项但使用不同的名字)。
为了理解TCP_DEFER_ACCEPT选项的具体思想，我们有必要大致阐述一下典型的HTTP客户/服务器交互过程。
请回想下TCP是如何与传输数据的目标建立连接的。
在网络上，在分离的单元之间传输的信息称为IP包(或IP数据报)。
一个包总有一个携带服务信息的包头，包头用于内部协议的处理，并且它也可以携带数据负载。
服务信息的典型例子就是一套所谓的标志，它把包标记代表TCP/IP协议栈内的特殊含义，例如收到包的成功确认等等。
通常，在经过“标记”的包里携带负载是完全可能的，但有时，内部逻辑迫使TCP/IP协议栈发出只有包头的IP包。
这些包经常会引发讨厌的网络延迟而且还增加了系统的负载，结果导致网络性能在整体上降低。
现在服务器创建了一个套接字同时等待连接。
TCP/IP式的连接过程就是所谓“3次握手”。
首先，客户程序发送一个设置SYN标志而且不带数据负载的TCP包(一个SYN包)。
服务器则以发出带SYN/ACK标志的数据包(一个SYN/ACK包)作为刚才收到包的确认响应。
客户随后发送一个ACK包确认收到了第2个包从而结束连接过程。
在收到客户发来的这个ACK包之后，服务器会唤醒一个接收进程等待数据到达。
当3次握手完成后，客户程序即开始把“有用的”的数据发送给服务器。
通常，一个HTTP请求的量是很小的而且完全可以装到一个包里。
但是，在以上的情况下，至少有4个包将用来进行双向传输，这样就增加了可观的延迟时间。
TCP网络函数介绍socketbindlistenacceptconnect
TCP网络函数介绍socketbindlistenacceptconnect/s/blog_a42fa3a801012jd5.html2012Linux系统是通过提供套接字(socket)来进行网络编程的.网络程序通过socket和其它几个函数的调用,会返回一个通讯的文件描述符,我们可以将这个描述符看成普通的文件的描述符来操作,这就是linux的设备无关性的好处.我们可以通过向描述符读写操作实现网络之间的数据交流.(一)socketint socket(int domain, int type,int protocol)domain:说明我们网络程序所在的主机采用的通讯协族(AF_UNIX 和AF_INET等).AF_UNIX只能够用于单一的Unix 系统进程间通信,而AF_INET是针对Internet的,因而可以允许在远程主机之间通信(当我们 man socket时发现 domain可选项是 PF_*而不是AF_*,因为glibc是posix的实现所以用PF代替了AF, 不过我们都可以使用的).type:我们网络程序所采用的通讯协议(SOCK_STREAM,SOCK_DGRAM等)SOCK_STREAM表明我们用的是TCP 协议,这样会提供按顺序的,可靠,双向,面向连接的比特流.SOCK_DGRAM 表明我们用的是UDP协议,这样只会提供定长的,不可靠,无连接的通信.protocol:由于我们指定了type,所以这个地方我们一般只要用0来代替就可以了 socket为网络通讯做基本的准备.成功时返回文件描述符,失败时返回-1,看errno可知道出错的详细情况.(二)bindint bind(int sockfd, struct sockaddr *my_addr, int addrlen) sockfd:是由socket调用返回的文件描述符.addrlen:是sockaddr结构的长度.my_addr:是一个指向sockaddr的指针. 在中有 sockaddr的定义struct sockaddr{unisgned short as_family;char sa_data[14];};不过由于系统的兼容性,我们一般不用这个头文件,而使用另外一个结构(struct sockaddr_in) 来代替.在中有sockaddr_in的定义struct sockaddr_in{unsigned short sin_family;unsigned short int sin_port;struct in_addr sin_addr;unsigned char sin_zero[8];}我们主要使用Internet所以sin_family一般为AF_INET,sin_addr设置为INADDR_ANY表示可以和任何的主机通信,sin_port是我们要监听的端口号.sin_zero[8]是用来填充的.bind将本地的端口同socket返回的文件描述符捆绑在一起.成功是返回0,失败的情况和socket一样(三)listenint listen(int sockfd,int backlog)sockfd:是bind后的文件描述符.backlog:设置请求排队的最大长度.当有多个客户端程序和服务端相连时, 使用这个表示可以介绍的排队长度.listen函数将bind的文件描述符变为监听套接字.返回的情况和bind一样.(四)acceptint accept(int sockfd, struct sockaddr *addr,int *addrlen)sockfd:是listen后的文件描述符.addr,addrlen是用来给客户端的程序填写的,服务器端只要传递指针就可以了. bind,listen和accept是服务器端用的函数,accept调用时,服务器端的程序会一直阻塞到有一个客户程序发出了连接. accept成功时返回最后的服务器端的文件描述符, 这个时候服务器端可以向该描述符写信息了. 失败时返回-1(五)connectint connect(int sockfd, struct sockaddr * serv_addr,int addrlen)sockfd:socket返回的文件描述符.serv_addr:储存了服务器端的连接信息.其中sin_add是服务端的地址addrlen:serv_addr的长度connect函数是客户端用来同服务端连接的.成功时返回0,sockfd 是同服务端通讯的文件描述符失败时返回-1.。
TCP粘包问题处理
TCP粘包问题处理1.什么是粘包？“粘包”这个说法已经被诟病很久了，既然坊间流传这个说法咱们就沿⽤吧，关于这个问题⽐较准确的解释可以参考下⾯⼏点：1. TCP是流传输协议,是⼀种⾯向连接的、可靠的、基于字节流的传输层通信协议2. TCP没有包的概念，它只负责传输字节序列，UDP是⾯向数据报的协议，所以不存在拆包粘包问题3. 应该由应⽤层来维护消息和消息的边界，即需要⼀个应⽤层协议，⽐如HTTP所以，本质上这是⼀个没有正确使⽤TCP协议的⽽产⽣的问题2.如何解决粘包？通常来说，⼀般有下⾯⼏种⽅式：1. 消息长度固定，提前确定包长度，读取的时候也安固定长度读取，适合定长消息包。
2. 使⽤特殊的字符或字符串作为消息的边界，例如 HTTP 协议的 headers 以“\r\n”为字段的分隔符3. ⾃定义协议，将消息分为消息头和消息体，消息头中包含表⽰消息总长度3.固定长度实现⾸先，来看⼀个存在粘包问题的例⼦：⼀、Server端：package mainimport ("log""net""strings")func main() {listen, err := net.Listen("tcp", "127.0.0.1:8000")if err != nil {panic(err)}defer listen.Close()for {conn, err := listen.Accept()if err != nil {panic(err)}for {data := make([]byte, 5) //每次10个元素_, err := conn.Read(data)if err != nil {log.Printf("%s\n", err.Error())break}receive := string(data)log.Printf("receive msg: %s", receive)send := []byte(strings.ToUpper(receive))_, err = conn.Write(send)if err != nil {log.Printf("send msg failed, error: %s", err.Error())}log.Printf("send msg: %s", receive)}}}⼆、Client端：这个服务的功能特别简单，客户端输⼊什么我就返回什么，客户端的话，这⾥我使⽤telnet来演⽰：jwang@jwang:~$ telnet 127.0.0.1 8000Trying 127.0.0.1...Connected to 127.0.0.1.Escape character is '^]'.abcdeABECE123456123456当你按回车键的时候telnet会在消息后⾯⾃动追加”\r\n“换⾏符并发送消息！从代码⾥⾯可以看到，在接受消息的时候服务端每次读取5个字节的内容输出并返回给客户端，如果输⼊的消息⼩于等于3（减去换⾏符）个字符的时候没有问题，但是当我们在telnet⾥⾯输⼊⼤于5个字符的内容的时候，这些数据的时候会被强⾏拆开处理。
如何正确关闭TCP连接
如何正确关闭TCP连接先上结论1. Read⽅法返回EOF错误，表⽰本端感知到对端已经关闭连接（本端已接收到对端发送的FIN）。
此后如果本端不调⽤Close⽅法，只释放本端的连接对象，则连接处于⾮完全关闭状态（CLOSE_WAIT）。
即⽂件描述符发⽣泄漏。
2. Write⽅法返回broken pipe错误，表⽰本端感知到对端已经关闭连接（本端已接收到对端发送的RST）。
此后本端可不调⽤Close⽅法。
连接处于完全关闭状态。
3. 由于golang⾥net.conn内部对⽂件描述符的所有io操作都有状态保护，所以即使在对端或本端关闭了连接之后，依然可以任意次数调⽤Read、Write、Close⽅法。
个⼈认为正确、简单、语义清晰、⾼效的做法：应该在Read或Write返回错误后调⽤Close。
不论是主动关闭还是被动关闭，调⽤Close后，不应该再Read或Write，并尽快释放net.conn对象(也可以理解为在关闭连接之前⼀定要确保对端不会再发数据过来，⼀定要处理完对端的数据后才能关闭)。
部分demo测试与分析我的测试环境： go version go1.13.1 darwin/amd64第三⽅⼯具： netstat和wireshark验证结论⼀假设我们有两个demo程序——server和client。
client主动连接上server后不做任何操作，直接关闭net.conn对象。
⽤于模拟主动关闭端。
代码如下：package mainimport ("log""net")func main(){conn, err := net.Dial("tcp", "127.0.0.1:8888")if err != nil {log.Println("dial error:", err)return}defer conn.Close()}server在accept新连接后，在新连接的处理函数中调⽤Read⽅法，Read返回io.EOF后不调⽤Close⽅法，直接退出处理函数，释放连接对象。
WEB应用中的高并发问题
WEB应⽤中的⾼并发问题WEB应⽤中的⾼并发问题⼤型⽹站，⽐如门户⽹站。
在⾯对⼤量⽤户访问、⾼并发请求⽅⾯，基本的解决⽅案集中在这样⼏个环节：使⽤⾼性能的服务器、⾼性能的数据库、⾼效率的编程语⾔、还有⾼性能的Web容器。
但是除了这⼏个⽅⾯，还没法根本解决⼤型⽹站⾯临的⾼负载和⾼并发问题。
这些解决思路在⼀定程度上也意味着更⼤的投⼊，并且这样的解决思路具备瓶颈，没有很好的扩展性，以下从平时的项⽬经验以及引⽤⼀些博客的思路来尝试解决⾼并发的情况。
0、⾸先需要关注数据库没错,⾸先是数据库,这是⼤多数应⽤所⾯临的⾸个SPOF（单点故障）。
尤其是Web2.0的应⽤，数据库的响应是⾸先要解决的。
可能最初是⼀台主机，当数据增加到100万以上，那么，数据库的效能急剧下降。
常⽤的优化措施是M-S（主-从）⽅式进⾏同步复制，将查询和操作和分别在不同的服务器上进⾏操作。
我推荐的是M-M-Slaves⽅式，2个主Master，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在⼀定时候切换。
之所以⽤2个M，是保证M不会⼜成为系统的SPOF。
Slaves可以进⼀步负载均衡，可以结合LVS,从⽽将select操作适当的平衡到不同的slaves 上。
以上架构可以抗衡到⼀定量的负载，但是随着⽤户进⼀步增加，你的⽤户表数据超过1千万，这时那个M变成了SPOF。
你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的⽅法是表分区，从业务层⾯上进⾏分区。
最简单的，以⽤户数据为例。
根据⼀定的切分⽅式，⽐如id，切分到不同的数据库集群去。
全局数据库⽤于meta数据的查询。
缺点是每次查询，会增加⼀次，⽐如你要查⼀个⽤户nightsailer,你⾸先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
TCP协议的窗口调整与拥塞避免策略
TCP协议的窗口调整与拥塞避免策略窗口调整是指TCP协议中用来控制发送数据的速率的机制。
在TCP协议中，发送方和接收方都有一个窗口大小的参数，用来表示接收方可以接收的数据量大小。
发送方发送数据时，会根据接收方的窗口大小来确定发送数据的速率，并且在接收方收到数据后，会反馈一个确认消息给发送方，告诉发送方可以发送多少数据。
如果发送方发送的数据超过了接收方的窗口大小，那么接收方会拒绝接收数据，从而导致数据丢失或者网络拥塞。
为了避免窗口大小导致的数据丢失或者网络拥塞问题，TCP协议引入了拥塞避免机制。
拥塞避免是指在网络流量过大导致网络拥堵时，TCP协议会主动减小发送数据的速率，从而避免网络拥塞的发生。
拥塞避免策略通常包括慢启动和拥塞避免两个阶段。
慢启动是TCP协议中用来逐渐增加发送数据速率的阶段。
在慢启动阶段，发送方会以指数增长的方式增加发送数据的速率，直到达到一个阈值为止。
当发送方发送的数据量超过一个阈值时，就会进入拥塞避免阶段。
在拥塞避免阶段，发送方会以线性增长的方式增加发送数据的速率，直到达到新的阈值为止。
如果网络出现拥塞，发送方会根据接收方的反馈消息减小发送数据的速率，从而避免网络拥塞的发生。
在窗口调整和拥塞避免策略中，有一些重要的参数需要进行调整，以优化网络的性能和稳定性。
其中，最重要的参数包括窗口大小、慢启动阈值、拥塞避免阈值等。
窗口大小是指发送方和接收方用来控制数据传输速率的参数。
发送方根据接收方的窗口大小来确定发送数据的速率，而接收方根据发送方的窗口大小来控制数据的接收速率。
通过调整窗口大小，可以有效地提高网络的传输效率和稳定性。
慢启动阈值是用来控制慢启动阶段的参数。
当发送方发送的数据超过慢启动阈值时，就会进入拥塞避免阶段。
通过调整慢启动阈值的大小，可以调整慢启动阶段发送数据的速率，以适应网络的带宽和延迟。
拥塞避免阈值是用来控制拥塞避免阶段的参数。
当发送方发送的数据超过拥塞避免阈值时，就会触发拥塞避免机制，减小发送数据的速率。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
ห้องสมุดไป่ตู้
经过测试发现，设置TCP_DEFER_ACCEPT选项后，服务器受到一个CONNECT请求后，操作系统不会Accept，也不会创建IO句柄。操作系统应该在若干秒，(但肯定远远大于上面设置的1s) 后，会释放相关的链接。但没有同时关闭相应的端口，所以客户端会一直以为处于链接状态。如果Connect后面马上有后续的发送数据，那么服务器会调用Accept接收这个链接端口。
感觉了一下，这个端口设置对于CONNECT链接上来而又什么都不干的攻击方式处理很有效。我们原来的代码都是先允许链接，然后再进行超时处理，比他这个有点Out了。不过这个选项可能会导致定位某些问题麻烦。
分享到： 上一篇：慎用TCP的选项SO_LINGER
下一篇：发现自己认识错误的C++问题还很多
ACE_DEBUG((LM_INFO," set_option TCP_DEFER_ACCEPT val(%d) ret(%d). /n", val, ret));
#endif
查询资料，TCP_DEFER_ACCEPT是一个很有趣的选项，
Linux 提供的一个特殊 setsockopt , 在 accept 的 socket 上面，只有当实际收到了数据，才唤醒正在 accept 的进程，可以减少一些无聊的上下文切换。代码如下。
val = 5;
setsockopt(srv_socket->fd, SOL_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val)) ;
里面 val 的单位是秒，注意如果打开这个功能，kernel 在 val 秒之内还没有收到数据，不会继续唤醒进程，而是直接丢弃连接。
一个很特别的TCP选项TCP_DEFER_ACCEPT .
分类： 网络通讯(TCP/UDP) 2009-08-09 23:34 1526人阅读 评论(1) 收藏 举报
昨天自己在测试端口是否能链接，发现下载服务器链接后，不会在制定的时间内被踢下线。觉得是个bug，决定调试一下，看了一下Jovi下载服务的代码，里面有相应的超时处理，觉得有点怪，继续检查日志，发现日志里面完全没有Accept处理的过程。简单叙述症状就是客户端Telnet成功，服务器端没有任何相应。
于是开始怀疑防火墙，换IP，换地点测试了半天无果。还是Sonicmao找到了问题原因。
Jovi的代码上有这样一段：
#ifndef WIN32
//TCP_DEFER_ACCEPT
int val = 1;
ret = peer_acceptor_.set_option(IPPROTO_TCP, TCP_DEFER_ACCEPT, &val, sizeof(val));