专栏首页老男孩成长之路搞了半天,终于弄懂了TCP Socket数据的接收和发送,太难~

搞了半天,终于弄懂了TCP Socket数据的接收和发送,太难~

本文将从上层介绍Linux上的TCP/IP栈是如何工作的,特别是socket系统调用和内核数据结构的交互、内核和实际网络的交互。写这篇文章的部分原因是解释监听队列溢出(listen queue overflow)是如何工作的,因为它与我工作中一直在研究的一个问题相关。

建好的连接怎么工作

先从建好的连接开始介绍,稍后将解释新建连接是如何工作的。

内核管理的每一个TCP文件描述符都是一个struct, 它记录TCP相关的信息(如序列号、当前窗口大小等等),以及一个接收缓冲区(receive buffer,或者叫receive queue)和一个写缓冲区(write buffer,或者叫write queue),后面我会交替使用术语bufferqueue。如果你对更多细节感兴趣,可以在Linux内核的net/sock.h中看到socket结构的实现。

当一个新的数据包进入网络接口(NIC)时,通过被NIC中断或通过轮询NIC的方式通知内核获取数据。通常内核是由中断驱动还是处于轮询模式取决于网络通信量;当NIC非常繁忙时,内核轮询效率更高,但如果NIC不繁忙,则可以使用中断来节省CPU周期和电源。Linux称这种技术为NAPI,字面意思是“新的api”。

当内核从NIC获取数据包时,它会对数据包进行解码,并根据源IP、源端口、目标IP和目标端口找出与该数据包相关联的TCP连接。此信息用于查找与该连接关联的内存中的struct sock。假设数据包是按顺序的到来的,那么数据有效负载就被复制到套接字的接收缓冲区中。此时,内核将执行read(2)或使用诸如select(2)epoll_wait(2)等I/O多路复用方式系统调用,唤醒等待此套接字的进程。

当用户态的进程实际调用文件描述符上的read(2)时,它会导致内核从其接收缓冲区中删除数据,并将该数据复制到此进程调用read(2)所提供的缓冲区中。

发送数据的工作原理类似。当应用程序调用write(2)时,它将数据从用户提供的缓冲区复制到内核写入队列中。随后,内核将把数据从写队列复制到NIC中,并实际发送数据。如果网络繁忙,如果TCP发送窗口已满,或者如果有流量整形策略等等,从用户实际调用write(2)开始,到向NIC传输数据的实际时间可能会有所延迟。

这种设计的一个结果是,如果应用程序读取速度太慢或写入速度太快,内核的接收和写入队列可能会被填满。因此,内核为读写队列设置最大大小。这样可以确保行为不可控的应用程序使用有限制的内存量。例如,内核可能会将每个接收和写入队列的大小限制在100KB。然后每个TCP套接字可以使用的最大内核内存量大约为200KB(因为与队列的大小相比,其他TCP数据结构的大小可以忽略不计)。

读语义

如果接收缓冲区为空,并且用户调用read(2),则系统调用将被阻塞,直到数据可用。

如果接收缓冲区是非空的,并且用户调用read(2),系统调用将立即返回这些可用的数据。如果读取队列中准备好的数据量小于用户提供的缓冲区的大小,则可能发生部分读取。调用方可以通过检查read(2)的返回值来检测到这一点。

如果接收缓冲区已满,而TCP连接的另一端尝试发送更多的数据,内核将拒绝对数据包进行ACK。这只是常规的TCP拥塞控制。

写语义

如果写入队列未满,并且用户调用写入,则系统调用将成功。如果写入队列有足够的空间,则将复制所有数据。如果写入队列只有部分数据的空间,那么将发生部分写入,并且只有部分数据将被复制到缓冲区。调用方通过检查write(2)的返回值来检查这一点。

如果写入队列已满,并且用户调用写入write(2)),则系统调用将被阻塞。

新建连接的工作机制

在上一节中,我们看到了已建立的连接如何使用接收和写入队列来限制为每个连接分配的内核内存量。使用类似的技术也用来限制为新连接保留的内核内存量。

从用户态的角度来看,新建立的TCP连接是通过在监听套接字上调用accept(2)来创建的。监听套接字是使用listen(2)系统调用的套接字。

accept(2)的原型采用一个套接字和两个字段来存储另一端套接字的信息。accept(2)返回的值是一个整数,表示新建立连接的文件描述符:

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

listen(2)的原型采用了一个套接字文件描述符和一个backlog参数:

int listen(int sockfd, int backlog);

backlog是一个参数,当用户没有足够快地调用accept(2)时,它控制内核将为新连接保留多少内存。

例如,假设您有一个阻塞的单线程HTTP服务器,每个HTTP请求大约需要100毫秒。在这种情况下,HTTP服务器将花费100毫秒处理每个请求,然后才能再次调用accept(2)。这意味着在最多10个 rps 的情况下不会有排队现象。如果内核中有10个以上的 rps,则有两个选择。

内核的第一个选择是根本不接受连接。例如,内核可以拒绝对传入的SYN包进行ACK。更常见的情况是,内核将完成TCP三次握手,然后使用RST终止连接。不管怎样,结果都是一样的:如果连接被拒绝,就不需要分配接收或写入缓冲区。这样做的理由是,如果用户空间进程没有足够快地接受连接,那么正确的做法是使新请求失败。反对这样做的理由是,这太粗暴(aggressive),尤其是如果新的连接爆发(bursty)的时候。

内核的第二个选择是接受连接并为其分配一个套接字结构(包括接收/写入缓冲区),然后将套接字对象排队以备以后使用。下次用户调用accept(2)将立即获得已分配的套接字, 而不是阻塞系统调用。

支持第二种方式的理由是,当处理速率或连接速率趋向于爆发时,它过于“宽宏大量”。例如,在我们刚才描述的服务器中,假设有10个新连接同时出现,然后这一秒中没有更多的连接出现。如果内核将新连接排队,那么在第这一秒中所有的请求都会被处理。如果内核采用拒绝新的连接的策略,那么即使进程本来能够满足请求速率的,也只有一个连接会成功。

不过有两个反对排队的论点。第一个问题是,过多的排队会导致分配大量的内核内存。如果内核正在分配带有大接收缓冲区的数千个套接字,那么内存使用量可能会快速增长,而用户空间进程甚至可能无法处理所有这些请求。另一个反对排队的论点是,它使应用程序在连接的另一端(客户机)看起来很慢。客户机将看到它可以建立新的TCP连接,但是当它尝试使用它们时,服务器似乎响应非常慢。所以建议在这种情况下,最好是让新的连接失败,因为这样可以提供更明显的服务器不正常的反馈。此外,如果服务器严重破坏了新的连接,客户机就可以知道要退让(back off);这是另一种拥塞控制形式。

监听队列(listen queue)和溢出

正如您可能怀疑的那样,内核实际上结合了这两种方法。内核将会对新连接进行排队,但只是一定数量的连接。内核将排队的连接数量由listen(2)的backlog参数控制。通常此值设置为相对较小的值。在Linux上,socket.hsomaxconn 的值设置为128,在kernel 2.4.25之前,这是允许的最大值。现在最大值是在/proc/sys/net/core/somaxconn中指定的,但是通常您会发现程序使用somaxconn(或更小的硬编码值)。

当监听队列填满时,新连接会被拒绝。这称为监听队列溢出。您可以通过读取/proc/net/netstat并检查ListenOverflows的值来观察情况。这是整个内核的全局计数器。据我所知,您无法获得每个监听套接字的监听溢出统计信息。

在编写网络服务器时,监控监听溢出非常重要,因为监听溢出不会从服务器的角度触发任何用户可见的行为。服务器将愉快地accept(2)每日的连接,而不返回任何连接被丢弃的迹象。例如,假设您为Python应用程序使用Nginx作为代理服务器。

如果python应用程序太慢,则可能导致nginx listen套接字溢出。当发生这种情况时,您将在nginx日志中看不到任何关于这一点的指示,您将一直看到200状态代码,像往常一样。因此,如果您只是监视应用程序的HTTP状态代码,您将无法看到阻止请求转发到应用程序的TCP错误。

来源 | https://urlify.cn/EjquQ3

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • TCP/IP网络协议的通俗理解

    前段时间做了一个开发,涉及到网络编程,开发过程比较顺利,但任务完成后始终觉得有一些疑惑。主要是因为对网络协议不太熟悉,对一些概念也没 弄清楚。后来我花了一些时间...

    wangxl
  • NIO,一本难念的经——分布式系统基础

    我们知道,分布式系统的基础是网络。因此,网络编程始终是分布式软件工程师和架构师的必备高端基础技能之一,而且随着当前大数据和实时计算技术的兴起,高性能 RPC 框...

    博文视点Broadview
  • 脑残式网络编程入门(二):我们在读写Socket时,究竟在读写什么?

    本文接上篇《脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手》,继续脑残式的网络编程知识学习 ^_^。

    JackJiang
  • 接地气讲解TCP协议和网络程序设计(深度好文)

    教科书的理解是这样的,它提供两台计算机之间可靠的数据传送,可以保证数据从一端发送到另一端接收时,数据能准确送达(那就是可靠的意思),而且抵达的数据的排列顺序和送...

    张晓衡
  • ESP8266_12 ESP8266客户端模式下的TCP通信

    上一节说了UDP,这一节就聊聊TCP,毕竟它俩经常同时出现。优缺点上一节也提了一下:安全性好,速度慢。

    MCU起航
  • Python Web学习笔记之TCP/IP、Http、Socket的区别

    经常在笔试、面试或者工作的时候听到这些协议,虽然以前没怎么涉及过,但至少知道这些是和网络编程密不可分的知识,作为一个客户端开发程序员,如果可以懂得网络编程的话,...

    Jetpropelledsnake21
  • 网络编程懒人入门(八):手把手教你写基于TCP的Socket长连接

    本文原作者:“水晶虾饺”,原文由“玉刚说”写作平台提供写作赞助,原文版权归“玉刚说”微信公众号所有,即时通讯网收录时有改动。

    JackJiang
  • Linux内核UDP收包为什么效率低?能做什么优化?

    现在很多人都在诟病Linux内核协议栈收包效率低,不管他们是真的懂还是一点都不懂只是听别人说的,反正就是在一味地怼Linux内核协议栈,他们的武器貌似只有DPD...

    IT大咖说
  • 网络知识扫盲:扒开 TCP 的外衣,我看清了 TCP 的本质

    从阅读和在看数来看,大家对这个系列还是比较期待的,所以这周我全身心地投入本篇文章的编写,用了整整 4个晚上的时间梳理了这篇关于 TCP 的重点知识,另外还参考 ...

    Python进阶者
  • 可能会搞砸你的面试:你知道一个TCP连接上能发起多少个HTTP请求吗?

    本文由原作者松若章原创发布,作者主页:zhihu.com/people/hrsonion/posts,感谢原作者的无私分享。

    JackJiang
  • JAVA服务器推送功能设计,消息方法总结

    IT架构圈
  • 闲话高并发的那些神话,看京东架构师如何把它拉下神坛

    高并发也算是这几年的热门词汇了,尤其在互联网圈,开口不聊个高并发问题,都不好意思出门。高并发有那么邪乎吗?动不动就千万并发、亿级流量,听上去的确挺吓人。但仔细想...

    京东技术
  • 理论经典:TCP协议的3次握手与4次挥手过程详解

    尽管TCP和UDP都使用相同的网络层(IP),TCP却向应用层提供与UDP完全不同的服务。TCP提供一种面向连接的、可靠的字节流服务。

    JackJiang
  • 怒解Workerman之select IO复用(十)

    在第八章和第九章的案例中,哥用socket和fork等基础为为大家表演了如下一波儿:

    老李秀
  • 面试官问了一下三次握手,我甩出这张脑图,他服了!

    在早期的网络传输中,也就存在TCP协议需要“握手”的过程,但早期的协议有一个缺陷:通信只能由客户端发起,做不到服务器主动向客户端推送信息。

    前端劝退师
  • 我是这么学习nginx 499的

    这篇文章从nginx的499着手,分析整个过程中是怎么产生499行为的,以及各种往返网络包出现的原因。说说我通过这个499问题一步一步分析的整个过程,不一定正确...

    Bug开发工程师
  • 直击案发现场!TCP 10 倍延迟的真相是?

    阿里妹导读:什么是经验?就是遇到问题,解决问题,总结方法。遇到的问题多了,解决的办法多了,经验自然就积累出来了。今天的文章是阿里技术专家蛰剑在工作中遇到的一个问...

    五月君
  • Python中send()和sendal

    通信术语 最大传输单元(Maximum Transmission Unit,MTU)是指一种通信协议的某一层上面所能通过的最大数据包大小(以字节为单位)

    py3study
  • TCP 粘包问题浅析及其解决方案

    最近一直在做中间件相关的东西,所以接触到的各种协议比较多,总的来说有TCP,UDP,HTTP等各种网络传输协议,因此楼主想先从协议最基本的TCP粘包问题搞起,把...

    haifeiWu

扫码关注云+社区

领取腾讯云代金券