linux网络编程--深入浅出send和recv
来源:互联网 发布:php构造函数和析构函数 编辑:程序博客网 时间:2024/05/21 17:07
接收缓冲区被TCP和UDP用来缓存网络上来的数据,一直保存到应用进程读走为止。对于TCP,如果应用进程一直没有读取,buffer满了之后,发生的动作是:通知对端TCP协议中的窗口关闭。这个便是滑动窗口的实现。保证TCP套接口接收缓冲区不会溢出,从而保证了TCP是可靠传输。因为对方不允许发出超过所通告窗口大小的数据。 这就是TCP的流量控制,如果对方无视窗口大小而发出了超过窗口大小的数据,则接收方TCP将丢弃它。 UDP:当套接口接收缓冲区满时,新来的数据报无法进入接收缓冲区,此数据报就被丢弃。UDP是没有流量控制的;快的发送者可以很容易地就淹没慢的接收者,导致接收方的UDP丢弃数据报。
以上便是TCP可靠,UDP不可靠的实现。
TCP_CORK TCP_NODELAY
这两个选项是互斥的,打开或者关闭TCP的nagle算法,下面用场景来解释
典型的webserver向客户端的应答,应用层代码实现流程粗略来说,一般如下所示:
if(条件1){
向buffer_last_modified填充协议内容“Last-Modified: Sat, 04 May 2012 05:28:58 GMT”;
send(buffer_last_modified);
}
if(条件2){
向buffer_expires填充协议内容“Expires: Mon, 14 Aug 2023 05:17:29 GMT”;
send(buffer_expires);
}
。。。
if(条件N){
向buffer_N填充协议内容“。。。”;
send(buffer_N);
}
对于这样的实现,当前的http应答在执行这段代码时,假设有M(M<=N)个条件都满足,那么会有连续的M个send调用,那是不是下层会依次向客户端发出M个TCP包呢?答案是否定的,包的数目在应用层是无法控制的,并且应用层也是不需要控制的。
我用下列四个假设场景来解释一下这个答案
由于TCP是流式的,对于TCP而言,每个TCP连接只有syn开始和fin结尾,中间发送的数据是没有边界的,多个连续的send所干的事情仅仅是:
假如socket的文件描述符被设置为阻塞方式,而且发送缓冲区还有足够空间容纳这个send所指示的应用层buffer的全部数据,那么把这些数据从应用层的buffer,拷贝到内核的发送缓冲区,然后返回。
假如socket的文件描述符被设置为阻塞方式,但是发送缓冲区没有足够空间容纳这个send所指示的应用层buffer的全部数据,那么能拷贝多少就拷贝多少,然后进程挂起,等到TCP对端的接收缓冲区有空余空间时,通过滑动窗口协议(ACK包的又一个作用----打开窗口)通知TCP本端:“亲,我已经做好准备,您现在可以继续向我发送X个字节的数据了”,然后本端的内核唤醒进程,继续向发送缓冲区拷贝剩余数据,并且内核向TCP对端发送TCP数据,如果send所指示的应用层buffer中的数据在本次仍然无法全部拷贝完,那么过程重复。。。直到所有数据全部拷贝完,返回。
请注意,对于send的行为,我用了“拷贝一次”,send和下层是否发送数据包,没有任何关系。
假如socket的文件描述符被设置为非阻塞方式,而且发送缓冲区还有足够空间容纳这个send所指示的应用层buffer的全部数据,那么把这些数据从应用层的buffer,拷贝到内核的发送缓冲区,然后返回。
假如socket的文件描述符被设置为非阻塞方式,但是发送缓冲区没有足够空间容纳这个send所指示的应用层buffer的全部数据,那么能拷贝多少就拷贝多少,然后返回拷贝的字节数。多涉及一点,返回之后有两种处理方式:
1.死循环,一直调用send,持续测试,一直到结束(基本上不会这么搞)。
2.非阻塞搭配epoll或者select,用这两种东西来测试socket是否达到可发送的活跃状态,然后调用send(高性能服务器必需的处理方式)。
综上,以及请参考本文前述的SO_RCVBUF和SO_SNDBUF,你会发现,在实际场景中,你能发出多少TCP包以及每个包承载多少数据,除了受到自身服务器配置和环境带宽影响,对端的接收状态也能影响你的发送状况。
至于为什么说“应用层也是不需要控制发送行为的”,这个说法的原因是:
软件系统分层处理、分模块处理各种软件行为,目的就是为了各司其职,分工。应用层只关心业务实现,控制业务。数据传输由专门的层面去处理,这样应用层开发的规模和复杂程度会大为降低,开发和维护成本也会相应降低。
再回到发送的话题上来:)之前说应用层无法精确控制和完全控制发送行为,那是不是就是不控制了?非也!虽然无法控制,但也要尽量控制!
如何尽量控制?现在引入本节主题----TCP_CORK和TCP_NODELAY。
cork:塞子,塞住
nodelay:不要延迟
TCP_CORK:尽量向发送缓冲区中攒数据,攒到多了再发送,这样网络的有效负载会升高。简单粗暴地解释一下这个有效负载的问题。假如每个包中只有一个字节的数据,为了发送这一个字节的数据,再给这一个字节外面包装一层厚厚的TCP包头,那网络上跑的几乎全是包头了,有效的数据只占其中很小的部分,很多访问量大的服务器,带宽可以很轻松的被这么耗尽。那么,为了让有效负载升高,我们可以通过这个选项指示TCP层,在发送的时候尽量多攒一些数据,把他们填充到一个TCP包中再发送出去。这个和提升发送效率是相互矛盾的,空间和时间总是一堆冤家!!
TCP_NODELAY:尽量不要等待,只要发送缓冲区中有数据,并且发送窗口是打开的,就尽量把数据发送到网络上去。
很明显,两个选项是互斥的。实际场景中该怎么选择这两个选项呢?再次举例说明
webserver,,下载服务器(ftp的发送文件服务器),需要带宽量比较大的服务器,用TCP_CORK。
涉及到交互的服务器,比如ftp的接收命令的服务器,必须使用TCP_NODELAY。默认是TCP_CORK。设想一下,用户每次敲几个字节的命令,而下层在攒这些数据,想等到数据量多了再发送,这样用户会等到发疯。这个糟糕的场景有个专门的词汇来形容-----粘(nian拼音二声)包。- linux网络编程--深入浅出send和recv
- linux网络编程--深入浅出send和recv
- 唯快不破:linux网络编程--深入浅出send和recv
- 网络编程send和recv
- Linux下Socket网络编程send和recv使用注意事项
- linux网络编程三:recv, send 的调用
- linux下网络编程send,recv,read,write的区别
- 网络编程中read/write和send/recv
- 再次深入理解TCP网络编程中的send和recv
- 网络编程学习笔记(recv和send函数)
- 转:理解TCP网络编程中的send和recv
- 网络编程send()和recv()详解
- Unix网络编程之读写操作recv和send函数
- 再次深入理解TCP网络编程中的send和recv
- 再次深入理解TCP网络编程中的send和recv
- 深入理解TCP网络编程中的send和recv
- 再次深入理解TCP网络编程中的send和recv
- TCP之深入浅出send和recv
- 图文讲解flashfxp教程 flashfxp详细教程
- JAVA 分布式事务的
- Java笔试题——Singleton单例模式
- 解析企业如何选择数据泄露防护系统?
- 【Java.Web】MVC —— 基于Servlet Controller的Model2 —— 示例
- linux网络编程--深入浅出send和recv
- Lock&Conditon实现线程间的通信
- 请设计一个函数可以把10进制的正整数转换为4位定长的36进制字符串,36进制规则0-9,A-Z,例如:1=‘000‘,10=’000A‘,100='002S',2000='01JK’
- 谁在威胁阿里巴巴?
- 【java】面向对象(三大特性)
- 第7周 项目3 简单分支问题体验
- 织梦DedeCMS频道页联动调用方法
- Oracle开发环境搭建
- 昨棕子浊昨踪棕篆捉座专咨孜琢着拙渍妆