1.从Linux源码看Socket(TCP)的握手握手listen及连接队列
2.一文了解Linux上TCP的几个内核参数调优
3.详细讲解Linux内核角度分析tcpdump原理(1)
4.如何测量和确定linux系统中tcp初始发送窗口的大小?
5.linux下安装tcpdump并用其抓包
6.畅谈linux下TCP（上）

从Linux源码看Socket(TCP)的listen及连接队列

       了解Linux内核中Socket (TCP)的"listen"及连接队列机制是深入理解网络编程的关键。本文将基于Linux 3.内核版本，源码从源码角度解析Server端Socket在进行"listen"时的握手握手具体实现。

       建立Server端Socket需要经历socket、源码bind、握手握手listen、源码数组filter源码accept四个步骤。握手握手本文聚焦于"listen"步骤，源码深入探讨其内部机理。握手握手

       通过socket系统调用，源码我们可以创建一个基于TCP的握手握手Socket。这里直接展示了与TCP Socket相关联的源码操作函数。

       接着，握手握手我们深入到"listen"系统调用。源码注意，握手握手glibc的INLINE_SYSCALL对返回值进行了封装，仅保留0和-1两种结果，并将错误码的绝对值记录在errno中。其中，backlog参数至关重要，设置不当会引入隐蔽的陷阱。对于Java开发者而言，框架默认backlog值较小（默认），这可能导致微妙的行为差异。

       进入内核源码栈，我们发现内核对backlog值进行了调整，限制其不超过内核参数设置的somaxconn值。

       核心调用程序为inet_listen。其中，除了fastopen外的逻辑（fastopen将在单独章节深入讨论）最终调用inet_csk_listen_start，将sock链入全局的listen hash表，实现对SYN包的高效处理。

       值得注意的是，SO_REUSEPORT特性允许不同Socket监听同一端口，实现内核级的负载均衡。Nginx 1.9.1版本启用此功能后，性能提升3倍。ttm净利润指标源码

       半连接队列与全连接队列是连接处理中的关键组件。通常提及的sync_queue与accept_queue并非全貌，sync_queue实际上是syn_table，而全连接队列为icsk_accept_queue。在三次握手过程中，这两个队列分别承担着不同角色。

       在连接处理中，除了qlen与sk_ack_backlog计数器外，qlen_young计数器用于特定场景下的统计。SYN_ACK的重传定时器在内核中以ms为间隔运行，确保连接建立过程的稳定。

       半连接队列的存在是为抵御半连接攻击，避免消耗大量内存资源。通过syn_cookie机制，内核能有效防御此类攻击。

       全连接队列的最大长度受到限制，超过somaxconn值的连接会被内核丢弃。若未启用tcp_abort_on_overflow特性，客户端可能在调用时才会察觉到连接被丢弃。启用此特性或增大backlog值是应对这一问题的策略。

       backlog参数对半连接队列容量产生影响，导致内核发送cookie校验时出现常见的内存溢出警告。

       总结而言，TCP协议在数十年的演进中变得复杂，深入阅读源码成为分析问题的重要途径。本文深入解析了Linux内核中Socket (TCP)的"listen"及连接队列机制，旨在帮助开发者更深入地理解网络编程。

一文了解Linux上TCP的几个内核参数调优

       在Linux操作系统中，TCP的内核参数调优是一项关键任务，其中涉及的参数众多。针对内网环境，以下是几个主要的TCP参数及其调优建议：

       1. **tcp_max_syn_backlog, somaxconn, tcp_abort_on_overflow**：这些参数控制内核TCP连接缓冲队列，防止因应用处理速度慢导致连接过多而溢出。应适当调大Backlog值，以避免连接在第三次握手后被意外丢弃，特别是共享储物柜app源码对于NIO应用，以确保连接稳定性。

       2. **tcp_syn_retries**：影响连接建立时的超时时间，建议设置为3次重传，以减少超时时间，对于Java，API提供了超时设置，但注意有些库可能未做此设置，可能导致不必要的延迟。

       3. **tcp_retries2**：内核计算超时时间的重传次数，对于ReadTimeout较大的情况，降低tcp_retries2有助于快速从宕机机器恢复响应。

       4. **tcp_slow_start_after_idle**：Linux默认开启这个参数来重置拥塞窗口，但对内网系统间调用影响不大，可能需要根据具体网络状况调整。

       5. **初始CWND大小**：Linux初始CWND设置可能限制了大请求的传输效率，建议根据系统需求调整到更合适的值，如Linux 2.6.以上版本的K左右。

       通过了解和调整这些参数，可以优化TCP连接性能，提高系统稳定性和响应速度。不过，每个场景的优化策略可能不同，务必结合实际环境进行调整。在学习过程中，可以加入交流群获取更多资源和支持。

详细讲解Linux内核角度分析tcpdump原理(1)

       tcpdump是Linux系统抓包工具，基于libpcap库，能根据定义对网络数据包进行截获。它支持过滤网络层、协议、主机、网络或端口，并使用逻辑语句去除无用信息。tcpdump能分析网络行为，如丢包重传、报文详细信息和TCP分组。码支付源码云端免挂通过保存捕获的数据包为pcap文件，使用wireshark打开，能更直观地分析问题。

       tcpdump使用libpcap进行包捕获，使用bpf机制进行完美过滤。libpcap是Unix/Linux平台下的数据包捕获函数库，独立于系统用户层，提供链路层旁路处理。libpcap安装步骤包括库安装、测试、编译和错误处理。

       在libpcap中，创建套接字使用AF_PACKET和SOCK_RAW，常用于抓包分析。socket函数调用__sock_create和packet_family_ops来创建socket，其中AF_PACKET模块对应创建函数packet_rcv，该函数用于接收链路层的包，然后根据应用层设置的过滤条件使用BPF进行过滤。

       当网络包接收时，tcpdump创建PF_PACKET套接字，通过注册prot_hook完成准备工作。网络接收数据包时，会调用netif_receive_skb和__netif_receive_skb_core，其中后者会遍历ptype_all并执行deliver_skb函数，该函数调用packet_rcv进行过滤并添加到接收缓存。

       当网络包发送时，Linux协议栈提供的报文发送函数会调用dev_queue_xmit或dev_hard_start_xmit，遍历ptype_all并执行deliver_skb和packet_rcv，将数据包发送给driver。最终，接收队列中的数据会copy给应用层，完成数据包的抓取。

       文章总结了tcpdump从创建套接字到收发包的流程，以及使用libpcap和BPF进行过滤的过程。下篇文章将详细分析BPF过滤的实现。

如何测量和确定linux系统中tcp初始发送窗口的wx zfb跑分系统源码大小?

       如何测量和确定Linux系统中TCP初始发送窗口的大小？

       答案涉及TCP协议的几个关键参数，包括rwnd（对端通告的窗口大小）和cwnd（本端的拥塞窗口）。在Linux实现中，发送窗口的初始大小由以下方式确定：wnd = min(rwnd, cwnd*mss)。其中mss是最大报文段大小。

       了解初始发送窗口大小的一种方法是进行握手操作。新建一个连接，然后使用tcpdump抓取握手包，同时使用ss -it命令查看连接的cwnd字段以及wscale字段。通过抓取的握手包获取到的wnd字段，再用wnd乘以2的wscale次幂计算出rwnd。最终利用上述计算公式得到初始发送窗口大小。

       另一种方法是直接查看Linux内核代码。寻找TCP_INIT_CWND宏定义，同样按照前述方法计算出rwnd。然后应用计算公式，得到初始发送窗口。

       如果需要自定义初始cwnd和初始rwnd（在接收端进行修改），可以通过iproute2包中的ip route命令的cwnd、initcwnd、initrwnd参数进行调整。具体操作细节请参考ip route的官方文档。

       通常情况下，除非对端接收设备老旧或运行的是非常老旧的操作系统，握手过程中对端反馈的初始rwnd通常大于cwnd*mss。因此，大多数情况下，初始cwnd已经接近于初始发送窗口的大小。

linux下安装tcpdump并用其抓包

       在Linux环境中，为了深入探究网络协议，抓包分析数据是一种有效手段。尽管Windows用户可以轻松通过Wireshark进行抓包，但在Linux环境下，尤其在空间有限或不支持Wireshark的版本中，安装和使用tcpdump成为更好的选择。本文将简述如何在Linux下安装tcpdump并进行抓包操作。

       首先，有两种安装tcpdump的方法。一是从源代码编译安装，可通过参考csdn博客（blog.csdn.net/tic_yx/article/details/...）获取详细的步骤。另一种更为便捷，就是在Ubuntu等系统中，通过命令行输入`sudo apt-get install tcpdump`，如果遇到安装问题，可以尝试更换国内的软件源，如清华大学源。

       在使用tcpdump时，常用命令包括实时查看抓包信息，将捕获的数据保存为pcap文件以便后续分析，以及通过过滤指定端口号并保存至文件。这样，即使在Linux上完成抓包，也可以方便地将文件传输到Windows系统，利用Wireshark进行深入分析。

       总的来说，Wireshark提供了强大的抓包和分析功能，但在Linux环境中不便安装时，使用tcpdump进行抓包并导出至Windows进行后续处理，不失为一个实用且灵活的解决方案。

畅谈linux下TCP（上）

        tcp 协议 是互联网中最常用的协议 ， 开发人员基本上天天和它打交道，对它进行深入了解。 可以帮助我们排查定位bug和进行程序优化。下面我将就TCP几个点做深入的探讨

        客户端：收到 ack 后 分配连接资源。 发送数据

        服务器 : 收到 syn 后立即 分配连接资源

        客户端：收到ACK， 立即分配资源

        服务器：收到ACK， 立即分配资源

        既然三次握手也不是%可靠， 那四次，五次，六次。。。呢? 其实都一样，不管多少次都有丢包问题。

        client 只发送一个 SYN， server 分配一个tcb， 放入syn队列中。 这时候连接叫半连接状态；如果server 收不到 client 的ACK， 会不停重试 发送 ACK-SYN 给client 。重试间隔 为 2 的 N 次方 叠加（2^0 , 2^1, 2^2 ....）；直至超时才释放syn队列中的这个 TCB;

        在半连接状态下， 一方面会占用队列配额资源，另一方面占用内存资源。我们应该让半连接状态存在时间尽可能的小

        当client 向一个未打开的端口发起连接请求时，会收到一个RST回复包

        当listen 的 backlog 和 somaxconn 都设置了得时候， 取两者min值

        Recv-Q 是accept 队列当前个数， Send-Q 设置最大值

        这种SYN洪水攻击是一种常见攻击方式，就是利用半连接队列特性，占满syn 队列的 资源，导致 client无法连接上。

        解决方案:

        为什么不像握手那样合并成三次挥手? 因为和刚开始连接情况，连接是大家都从0开始， 关闭时有历史包袱的。server(被动关闭方) 收到 client(主动关闭方) 的关闭请求FIN包。 这时候可能还有未发送完的数据，不能丢弃。 所以需要分开。事实可能是这样

        当然，在没有待发数据，并且允许 Delay ACK 情况下， FIN-ACK合并还是非常常见的事情，这是三次挥手是可以的。

        同上

        CLOSE_WAIT 是被动关闭方才有的状态。

        被动关闭方 [收到 FIN 包 发送 ACK 应答] 到 [发送FIN， 收到ACK ] 期间的状态为 CLOSE_WAIT， 这个状态仍然能发送数据。 我们叫做半关闭, 下面用个例子来分析:

        这个是我实际生产环境碰到的一个问题，长连接会话场景，server端收到client的rpc call 请求1，处理发现请求包有问题，就强制关闭结束这次会话， 但是 因为client 发送 第二次请求之前，并没有去调用recv，所以并不知道 这个连接被server关闭， 继续发送 请求2 ， 此时是半连接，能够成功发送到对端机器，但是recv结果后，遇到连接已经关闭错误。

        如果 client 和 server 恰好同时发起关闭连接。这种情况下，两边都是主动连接，都会进入 TIME_WAIT状态

        1、被动关闭方在LAST_ACK状态(已经发送FIN)，等待主动关闭方的ACK应答，但是 ACK丢掉， 主动方并不知道，以为成功关闭。因为没有TIME_WAIT等待时间，可以立即创建新的连接， 新的连接发送SYN到前面那个未关闭的被动方，被动方认为是收到错误指令，会发送RST。导致创建连接失败。

        2、主动关闭方断开连接，如果没有TIME_WAIT等待时间，可以马上建立一个新的连接，但是前一个已经断开连接的，延迟到达的数据包。 被新建的连接接收，如果刚好seq 和 ack字段 都正确, seq在滑动窗口范围内(只能说机率非常小，但是还是有可能会发生)，会被当成正确数据包接收，导致数据串包。 如果不在window范围内，则没有影响( 发送一个确认报文（ack 字段为期望ack的序列号，seq为当前发送序列号），状态变保持原样)

        TIME_WAIT 问题比较比较常见，特别是CGI机器，并发量高，大量连接后段服务的tcp短连接。因此也衍生出了多种手段解决。虽然每种方法解决不是那么完美，但是带来的好处一般多于坏处。还是在日常工作中会使用。

1、改短TIME_WAIT 等待时间

        这个是第一个想到的解决办法，既然等待时间太长，就改成时间短，快速回收端口。但是实际情况往往不乐观，对于并发的机器，你改多短才能保证回收速度呢，有时候几秒钟就几万个连接。太短的话，就会有前面两种问题小概率发生。

        2、禁止Socket lingering

        这种情况下关闭连接，会直接抛弃缓冲区中待发送的数据，会发送一个RST给对端，相当于直接抛弃TIME_WAIT， 进入CLOSE状态。同样因为取消了 TIME_WAIT 状态，会有前面两种问题小概率发生。

        3、tcp_tw_reuse

        net.ipv4.tcp_tw_reuse选项是 从 TIME_WAIT 状态的队列中，选取条件：1、remote 的 ip 和端口相同， 2、选取一个时间戳小于当前时间戳； 用来解决端口不足的尴尬。

        现在端口可以复用了，看看如何面对前面TIME_WAIT 那两种问题。 我们仔细回顾用一下前面两种问题。都是在新建连接中收到老连接的包导致的问题， 那么如果我能在新连接中识别出此包为非法包，是不是就可以丢掉这些无用包，解决问题呢。

        需要实现这些功能，需要扩展一下tcp 包头。 增加 时间戳字段。 发送者 在每次发送的时候。 在tcp包头里面带上发送时候的时间戳。 当接收者接收的时候，在ACK应答中除了TCP包头中带自己此时发送的时间戳，并且把收到的时间戳附加在后面。也就是说ACK包中有两个时间戳字段。结构如下:

        那我们接下来一个个分析tcp_tw_reuse是如何解决TIME_WAIT的两个问题的

        4、tcp_tw_recycle

        tcp_tw_recycle 也是借助 timestamp机制。顾名思义， tcp_tw_reuse 是复用 端口，并不会减少 TIME-WAIT 数量。你去查询机器上TIME-WAIT 数量，还是 几千几万个，这点对有强迫症的同学感觉很不舒服。tcp_tw_recycle 是 提前 回收 TIME-WAIT资源。会减少 机器上 TIME-WAIT 数量。

        tcp_tw_recycle 工作原理是。

一文从linux源码看socket的close基本概括

       理解TCP关闭过程的关键在于四次挥手，这个过程是主动关闭、被动关闭和同时关闭的统一体现。在主动关闭close(fd)的过程中，通过C语言中的close(int fd)函数调用系统调用sys_close，进而执行filp_close方法。随后，fput函数处理多进程中的socket引用问题，确保父进程也正确关闭socket。在f_op->release的实现中，我们关注socket与file的关系以及close(fd)调用链。随着状态机的变迁，TCP从FIN_WAIT1变迁至FIN_WAIT2，设置一个TCP_FIN_WAIT2定时器，防止由于对端未回应导致的长时间等待。FIN_WAIT2状态等待对端的FIN，完成最后两次挥手。接收对端FIN后，状态变化至time_wait，原socket资源被回收，并在时间等待超时后从系统中清除。在被动关闭中，接收FIN进入close_wait状态，应用关闭连接时改变状态为last_ack，并发送本端的FIN。被动关闭的后两次挥手后，连接关闭。出现大量close_wait通常与应用检测到对端FIN时未及时关闭有关，解决方法包括调整连接池的参数或加入心跳检测。操作系统通过包活定时器在超时后强制关闭连接。进程退出时会关闭所有文件描述符，再次触发filp_close函数。在Java中，通过重写finalize方法，GC会在释放内存时关闭未被引用的socket，但不可完全依赖GC来管理socket资源，以避免潜在的内存泄露问题。总结，深入理解TCP关闭过程有助于优化网络应用程序的性能和稳定性，同时阅读Linux内核源代码需要耐心和系统性的方法。

从 Linux源码 看 Socket(TCP)的accept

       从 Linux 源码角度探究 Server 端 Socket 的 Accept 过程（基于 Linux 3. 内核），以下是一系列关键步骤的解析。

       创建 Server 端 Socket 需依次执行 socket、bind、listen 和 accept 四个步骤。其中，socket 系统调用创建了一个 SOCK_STREAM 类型的 TCP Socket，其操作函数为 TCP Socket 所对应的 ops。在进行 Accept 时，关键在于理解 Accept 的功能，即创建一个新的 Socket 与对端的 connect Socket 进行连接。

       在具体实现中，核心函数 sock->ops->accept 被调用。关注 TCP 实现即 inet_stream_ops->accept，其进一步调用 inet_accept。核心逻辑在于 inet_csk_wait_for_connect，用于管理 Accept 的超时逻辑，避免在超时时惊群现象的发生。

       EPOLL 的实现中，"惊群"现象是由水平触发模式下 epoll_wait 重新塞回 ready_list 并唤醒多个等待进程导致的。虽然 epoll_wait 自身在有中断事件触发时不惊群，但水平触发机制仍会造成类似惊群的效应。解决此问题，通常采用单线程专门处理 accept，如 Reactor 模式。

       针对"惊群"问题，Linux 提供了 so_reuseport 参数，允许多个 fd 监听同一端口号，内核中进行负载均衡（Sharding），将 accept 任务分散到不同 Socket 上。这样，可以有效利用多核能力，提升 Socket 分发能力，且线程模型可改为多线程 accept。

       在 accept 过程中，accept_queue 是关键成员，用于填充添加待处理的连接。用户线程通过 accept 系统调用从队列中获取对应的 fd。值得注意的是，当用户线程未能及时处理时，内核可能会丢弃三次握手成功的连接，导致某些意外现象。

       综上所述，理解 Linux Socket 的 Accept 过程需要深入源码，关注核心函数与机制，以便优化 Server 端性能，并有效解决"惊群"等问题，提升系统处理能力。

linux如何实现tcp/ip协议?

       在深入探讨 Linux 中 TCP/IP 协议的实现时，我们不仅需要理解基本的三次握手过程，还需洞悉内核底层的复杂操作。三次握手不仅涉及状态流转，还包括端口选择、半连接队列、syncookie、全连接队列、重传计时器等关键操作。这些深入了解将显著提升你对线上问题的把握与理解能力，在面试中无疑能为你加分。

       三次握手的主要流程如下：

       服务器通过创建 socket、绑定端口、listen 监听并接受客户端请求。

       客户端创建 socket，调用 connect 连接服务器。

       这看似简单的几个系统调用，背后却蕴含着内核底层的复杂操作。以下是对三次握手过程的内部操作详细解析：

       一、服务器的 listen

       服务器在提供服务前会 listen，此时内核会计算半连接队列长度，据此申请内存用于管理半连接队列对象，同时将队列挂到接收队列上。全连接队列作为链表形式初始化，等待连接请求。

       二、客户端 connect

       客户端发起 connect 请求时，将状态设置为 TCP_SYN_SENT，通过动态选择端口，构造并发送 SYN 握手包，同时启动重传定时器。

       三、服务器响应 SYN

       服务器响应 SYN 包，检查全/半连接队列，构造 SYNACK 并发送，同时将握手信息添加到半连接队列，开启重传定时器。

       四、客户端响应 SYNACK

       客户端收到 SYNACK 后，修改状态为 ESTABLISHED，清除重传定时器，开启保活计时器，并发送第三次握手的 ACK。

       五、服务器响应 ACK

       服务器响应 ACK，检查全连接队列，若未满则创建新 socket，添加到全连接队列，设置连接状态为 ESTABLISHED。

       六、服务器 accept

       accept 操作从全连接队列取出连接请求，返回给用户进程。

       通过以上解析，你能够更深入地理解三次握手的过程，对于线上问题排查具有极大帮助。同时，内核中的握手过程还涉及丢包重传、计时器控制等细节，对这些问题的了解也有助于优化网络性能。深入理解这些内部机制，将使你具备处理复杂网络问题的能力。