手机混用闪存到底是真是假？
|
大家可能要问，为何上面的抓包上显示窗口其实是5792，并不是1460*4为5840呢?这是因为1460想表达的意义是：将1500字节的MTU去除了20字节的IP头、20字节的TCP头以后，一个最大报文能够承载的有效数据长度。但有些网络中，会在TCP的可选头部里，使用12字节作为时间戳使用，这样，有效数据就是MSS再减去12，初始窗口就是(1460-12)*4=5792，这与窗口想表达的含义是一致的，即：我能够处理的有效数据长度。 在linux3以后的版本中，初始窗口调整到了10个MSS大小，这主要来自于GOOGLE的建议。原因是这样的，接收窗口虽然常以指数方式来快速增加窗口大小(拥塞阀值以下是指数增长的，阀值以上进入拥塞避免阶段则为线性增长，而且，拥塞阀值自身在收到128以上数据报文时也有机会快速增加)，若是传输视频这样的大数据，那么随着窗口增加到(接近)最大读缓存后，就会“开足马力”传输数据，但若是通常都是几十KB的网页，那么过小的初始窗口还没有增加到合适的窗口时，连接就结束了。这样相比较大的初始窗口，就使得用户需要更多的时间(RTT)才能传输完数据，体验不好。 那么这时大家可能有疑问，当窗口从初始窗口一路扩张到最大接收窗口时，最大接收窗口就是最大读缓存吗?
不是，因为必须分一部分缓存用于应用程序的延时报文读取。到底会分多少出来呢?这是可配的系统选项，如下： 可以看到初始的接收窗口是5792，当然也远小于最大接收缓存(稍后介绍的tcp_rmem[1])。 这当然是有原因的，TCP协议需要考虑复杂的网络环境，所以使用了慢启动、拥塞窗口(参见 高性能网络编程2----TCP消息的发送 )，建立连接时的初始窗口并不会按照接收缓存的最大值来初始化。这是因为，过大的初始窗口从宏观角度，对整个网络可能造成过载引发恶性循环，也就是考虑到链路上各环节的诸多路由器、交换机可能扛不住压力不断的丢包(特别是广域网)，而微观的TCP连接的双方却只按照自己的读缓存上限作为接收窗口，这样双方的发送窗口(对方的接收窗口)越大就对网络产生越坏的影响。慢启动就是使初始窗口尽量的小，随着接收到对方的有效报文，确认了网络的有效传输能力后，才开始增大接收窗口。
不同的linux内核有着不同的初始窗口，我们以广为使用的linux2.6.18内核为例，在以太网里，MSS大小为1460，此时初始窗口大小为4倍的MSS，简单列下代码(*rcv_wnd即初始接收窗口)： TCP连接所用内存主要由读写缓存决定，而读写缓存的大小只与实际使用场景有关，在实际使用未达到上限时，SO_SNDBUF、SO_RCVBUF是不起任何作用的。对读缓存来说，接收到一个来自连接对端的TCP报文时，会导致读缓存增加，当然，如果加上报文大小后读缓存已经超过了读缓存上限，那么这个报文会被丢弃从而读缓存大小维持不变。什么时候读缓存使用的内存会减少呢?当进程调用read、recv这样的方法读取TCP流时，读缓存就会减少。因此，读缓存是一个动态变化的、实际用到多少才分配多少的缓冲内存，当这个连接非常空闲时，且用户进程已经把连接上接收到的数据都消费了，那么读缓存使用内存就是0。 写缓存也是同样道理。当用户进程调用send或者write这样的方法发送TCP流时，就会造成写缓存增大。当然，如果写缓存已经到达上限，那么写缓存维持不变，向用户进程返回失败。而每当接收到TCP连接对端发来的ACK确认了报文的成功发送时，写缓存就会减少，这是因为TCP的可靠性决定的，发出去报文后由于担心报文丢失而不会销毁它，可能会由重发定时器来重发报文。因此，写缓存也是动态变化的，空闲的正常连接上，写缓存所用内存通常也为0。 因此，只有当接收网络报文的速度大于应用程序读取报文的速度时，可能使读缓存达到了上限，这时这个缓存使用上限才会起作用。所起作用为：丢弃掉新收到的报文，防止这个TCP连接消耗太多的服务器资源。同样，当应用程序发送报文的速度大于接收对方确认ACK报文的速度时，写缓存可能达到上限，从而使send这样的方法失败，内核不为其分配内存。 二、缓存的大小与TCP的滑动窗口到底有什么关系? (1)滑动窗口的大小与缓存大小肯定是有关的，但却不是一一对应的关系，更不会与缓存上限具有一一对应的关系。因此，网上很多资料介绍rmem_max等配置设置了滑动窗口的最大值，与我们tcpdump抓包时看到的win窗口值完全不一致，是讲得通的。下面我们来细探其分别在哪里。 读缓存的作用有2个：1、将无序的、落在接收滑动窗口内的TCP报文缓存起来;2、当有序的、可以供应用程序读取的报文出现时，由于应用程序的读取是延时的，所以会把待应用程序读取的报文也保存在读缓存中。所以，读缓存一分为二，一部分缓存无序报文，一部分缓存待延时读取的有序报文。这两部分缓存大小之和由于受制于同一个上限值，所以它们是会互相影响的，当应用程序读取速率过慢时，这块过大的应用缓存将会影响到套接字缓存，使接收滑动窗口缩小，从而通知连接的对端降低发送速度，避免无谓的网络传输。当应用程序长时间不读取数据，造成应用缓存将套接字缓存挤压到没空间，那么连接对端会收到接收窗口为0的通知，告诉对方：我现在消化不了更多的报文了。
反之，接收滑动窗口也是一直在变化的，我们用tcpdump抓三次握手的报文： （编辑：济宁站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
