计算机网络&操作系统答疑.docx

《计算机网络&操作系统答疑.docx》由会员分享，可在线阅读，更多相关《计算机网络&操作系统答疑.docx（11页珍藏版）》请在第一文库网上搜索。

1、计算机网络&操作系统答疑大家好，我是小林。最近每天都挺多人问一些问题，基本上都是看图解网络和图解系统文章时的提出的问题。我也会在每天忙完后，抽1个时间去回答大家的问题，但是不一定每个人我都能回答的到，因为有时候信息太多，可能没有看到你的问题。有些读者问的问题也很有代表性的，也是值得分享出来的，所以我打算不定期收集一波问题，在公众号分享一下。可能有些问题，也是你们的疑惑点。这次，我就收集了几个最近大家问的问题。 TCP头部中长度字段的长度只有4字节，为什么可以包含TCP option的长度？ TCP时间戳回绕了怎么办？ 为什么重复的ACK无法判断要重传哪些数据？ 为什么10多路复用要搭配非阻塞1

2、0? 自旋锁为什么是悲观锁，而不是乐观锁？ 关于 HTTP cookie sessionid token 的问题 HTTP/1.0可以开启长连接吗？TCP头部中长度字段的长度只有4位，为什么可以包含TCP option的长度？先给大家看看TCP包头结构:数据之前有位读者的疑惑，说TCP的首部长度字段只有4位，这样算最大值就是15,而首部长度字段是定义TCP包头的长度的，按道理TCP最大的包头的长度是：固定包头20字节+选项最长40字节=60字节。为什么可以用4位的首部长度字段来定义TCP包头的长度？我的回答：首先，首部长度字段确是定义TCP包头的长度的，但是不是你这样计算的。首部长度字段的意思

3、是有多少个4字节，比如如果首部长度为1111（最大值）,十进制就是15,所以首部长度字段的意思是有15个4字节，也就是15*4 = 60 oTCP时间回绕了怎么办？在这篇文章中：TCP是如何避免历史报文的？。提到因为TCP序列号会有回绕的问题，所以需要用时间戳的机制来判断历史报文（简称PAWS）,然后有读者问了这么一个问题: 如果时间戳也回绕了怎么办时间戳的大小是32 bit,所以理论上也是有回绕的可能性的。时间戳回绕的速度只与对端主机时钟频率有关。Linux以本地时钟计数（jiffies）作为时间戳的值，不同的增长时间会有不同的问题：如果时钟计数加1需要1ms,则需要约24.8天才能回绕一半

4、，只要报文的生存时间小于这个值的话判断新旧数据就不会出错。如果时钟计数提高到lus力口 1,则回绕需要约71.58分钟才能同绕，这时问题也不大，因为网络中旧报文几乎不可能生存超过70分钟，只是如果70分钟没有报文收发则会有一个包越过PAWS （这种情况会比较多见，相比之下24天没有数据传输的TCP连接少之又少），但除非这个包碰巧是序列号同绕的旧数据包而被放入接收队列（太巧了吧），否则也不会有问题；如果时钟计数提高到0.1 us加1回绕需要7分钟多一点，这时就可能会有问题了，连接如果7分钟没有数据收发就会有一个报文越过PAWS,对于TCP连接而言这么短的时间内没有数据交互太常见了吧！这样的话会频

5、繁有包越过PAWS检查，从而使得旧包混入数据中的概率大大增加；Linux在PAWS检查做了一个特殊处理，如果一个TCP连接连续24天不收发数据则在接收第一个包时基于时间戳的PAWS会失效，也就是可以PAWS函数会放过这个特殊的情况，认为是合法的，可以接收该数据包。static ini ine bool tcp paws check (const struct tcp options received*rx_opt, int paws_win)我的回答:如果seq2和seq3都丢了 ,接收方收到scq4会回ack2,收到scq5会回ack2,seq6会回ack2o三个ack都是一样的，你怎么知道

6、是要重传seq2,还是seq2、seq3 呢?这三个都是重复的ACK报文，scq和ack都是一样的，如下图抓包图:Source Port: 38760Destination Port: 80(Stream index: 0TCP Segment Len: 0Sequence number: 1 (relative sequence number)Sequence number (raw): 764338729TCP重复确认和快速重传的一个案例，用Wireshark分析，显示如下:j (Hext sequence number： 1 (rwlativ sequent numberH编号 1 数据

7、包期望的下一个 Sq 是 1Acknowledgment number: 1 (relative ack nuter)Acknowledgment number (raw): 13109731861011 Header Length: 44 bytes (11)数据包1期望的下一个数据包Seq是1,但是数据包2发送的Seq却是10945,说明收到的是乱序数据包,于是回了数据包3 ,还是同样的Seq = 1, Ack = 1.这表明是重复的ACK;数据包4和6依然是乱序的数据包,于是依然回了重复的ACK；当对方收到三次重复的ACK后，于是就快速重传了 Seq = 1、Len = 1368的数据包

8、8;当收到重传的数据包后，发现Seq = 1是期望的数据包，于是就发送了个确认收到快速重传的ACK所以，无法根据重复的ACK来判断要重传哪些数据的（注意是哪些，不是哪个），想要具体实现要重传哪些数据，就要使用sack这个机制（具体在图解网络已经介绍了，这里不多说啦）。自旋锁为什么是悲观锁，而不是乐观锁？我图解系统里提到，白旋锁是悲观锁，然后有个读者说白旋锁底层是CAS实现的,为什么不是乐观锁呢？群主自旋锁是乐观锁吧底层不是cas结构吗我的回答:乐观锁是先修改同步资源，再验证有没有发生冲突。悲观锁是修改共享数据前，都要先加锁，防止竞争。CAS是乐观锁没错，但是CAS和自旋锁不同之处，自旋锁基于C

9、AS加了 while或者睡眠CPU的操作而产生自旋的效果，加锁失败会忙等待直到拿到锁，自旋锁是要需要事先拿到锁才能修改数据的，所以算悲观锁。为什么10多路复用要搭配非阻塞10?这个问题在man select就有说明了。Under Linux, select () may report a socket file descriptor as ready forreading。 while nevertheless a subsequent read blocks. This could forexample happen when data has arrived but upon examin

10、ation has wrong checksumand is discarded. There may be other circumstances in which a filedescriptor is spuriously reported as ready. Thus i t may be safer to use0 NON BLOCK on sockets that should not block.翻译一下就是：在Linux下，selectO可能会将套接字文件描述符报告为“准备好读取”，但随后会出现读取块。例如，当数据到达但检查时校验和错误并被丢弃时，可能会发生这种情况。可能存在文

11、件描述符被虚假报告为己就绪的其他情况。因此，在不应阻塞的套接字上使用O_NONBLOCK可能更安全。简单来说，select返回了读事件，但是该内核中不一定有数据可读，因为有可能被内核丢弃。关于 HTTP cookie sessionid、token 的问题有位读者问下面3个问题：1 .看到网上说cookie不安全，session安全。因为cookie存在了浏览器客户端，session存在了服务器。劫持了cookie可以模拟用户登录，但是seesionld不也是存在cookie里的吗，那么sessionld一样可以被劫持然后拿sessionld去模拟登录，那这样cookie和session就没有

12、区别了呀，都是不安全的。2 . token是用户登录后，服务器对用户账号密码进行了一次加密后生成的token,存储在了浏览器。那么cookie也是用户登录后服务器返回了set-cookie,那么我可以不可以理解为token和cookie其实没有区别，只不过token比cookie在服务端多进行了一次加密而已？3 .在网上看到说sessionld在浏览器关闭后就失效了，那么再打开浏览器是不是还需要重新登陆呢？ cookie也需要重新登陆吗？由于问题比较多，我也写了一个小短文回答他的问题。回答问题一:一、cookie 和 sessionid 安全问题cookie是HTTP头部字段的一个东西，里面存

13、放独特的身份标识数据。如果这个身份标识数据是用户密码，那肯定不安全呀，因为cookie是明文显示的。sessionid也是身份标识数据，只不过是由服务端生存的标识，就是单纯的一个id,没有任何用户密码信息，即使被sessionid知道了，也不能知道用户密码。sessionid 一般都是放在cookie中传给对方的，所以cookie就是运载sessionid的一种方式。上面的安全层面在于会不会泄漏用户登陆密码，取决于身份标识数据存的是什么。但是Cookie安全问题在于，在JS脚本里可以用document.cookie来读写Cookie数据，有可能会导致“跨站脚本”（XSS）攻击窃取数据。可以用以

14、下三个方法来防止：属性HttpOnly”会告诉浏览器，此Cookie只能通过浏览器HTTP协议传输，禁止其他方式访问，浏览器的JS引擎就会禁用document.cookie等一切相关的API,脚本攻击也就无从谈起了。另一个属性SameSite”可以防范“跨站请求伪造（XSRF）攻击，设置成“SameSite=Strict”可以严格限定Cookie不能随着跳转链接跨站发送，而“SameSitedax”则略宽松一点，允许GET/HEAD等安全方法，但禁止POST跨站发送。还有一个属性叫“Secure）表示这个Cookie仅能用HTTPS协议加密传输，明文的HTTP协议会禁止发送。但Cookie本身

15、不是加密的，浏览器里还是以明文的形式存在。回答问题二:二、token与 sessionid有什么区别？不是简单加不加密的区别，主要区别如下：I-Session是存储在服务器端的，若服务器做了负载均衡，用户的下一次请求可能会被定向到其它服务器节点，若那台节点上没有用户的Session信息，就会导致会话验证失败。所以Session默认机制下是不适合分布式部署的。若Session没有持久化落地存储，一旦服务器重启，Session数据会丢失。 Token是放在客户端存储的，采用了时间换空间策略，它也是无状态的，所以在分布式环境中应用广泛。 Session是一种记录服务器和客户端会话状态的机制，使服务端有状态化，可以记录会话信息。而Token是令牌，访问资源接口 (API)时所需要的资源凭证。Token使服务端无状态化，不会存储会话信息。 Session和Token并不矛盾，