《计算机网络&操作系统答疑.docx》由会员分享，可在线阅读，更多相关《计算机网络&操作系统答疑.docx（11页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、计算机网络&操作系统答疑大家好，我是小林。最近每天都挺多人问一些问题，基本上都是看图解网络和图解系统文章时的提出的 问题。我也会在每天忙完后，抽1个时间去回答大家的问题，但是不一定每个人我都能 回答的到，因为有时候信息太多，可能没有看到你的问题。有些读者问的问题也很有代表性的，也是值得分享出来的，所以我打算不定期收集 一波问题，在公众号分享一下。可能有些问题，也是你们的疑惑点。这次，我就收集了几个最近大家问的问题。 TCP头部中长度字段的长度只有4字节，为什么可以包含TCP option的长度？ TCP时间戳回绕了怎么办？ 为什么重复的ACK无法判断要重传哪些数据？ 为什么10多路复用要搭配非
2、阻塞10? 自旋锁为什么是悲观锁，而不是乐观锁？ 关于 HTTP cookie、sessionid token 的问题HTTP/1.0可以开启长连接吗？TCP头部中长度字段的长度只有4位，为什么可以包含TCP option的长度？先给大家看看TCP包头结构:回答问题二:二、token与 sessionid 有什么区别？不是简单加不加密的区别，主要区别如下：ISession是存储在服务器端的，若服务器做了负载均衡， 用户的下一次请求可能会被定向到其它服务器节点，若那 台节点上没有用户的Session信息，就会导致会话验证失 败。所以Session默认机制下是不适合分布式部署的。若 Session
3、没有持久化落地存储，一旦服务器重启，Session 数据会丢失。 Token是放在客户端存储的，采用了时间换空间策略，它 也是无状态的，所以在分布式环境中应用广泛。 Session是一种记录服务器和客户端会话状态的机制，使 服务端有状态化，可以记录会话信息。而Token是令牌， 访问资源接口（API）时所需要的资源凭证。Token使服务 端无状态化，不会存储会话信息。 Session和Token并不矛盾，作为身份认证Token安全性 比Session好，因为每一个请求都有签名还能防止监听以 及重放攻击，而Session就必须依赖链路层来保障通讯安 全了。如果你需要实现有状态的会话，仍然可以增加
4、 Session来在服务器端保存一些状态。所谓Session认证只是简单的把User信息存储到Session 里，因为Session的不可预测性，暂且认为是安全的。 而Token ,如果指的是OAuth Token或类似的机制的话， 提供的是认证和授权，认证是针对用户，授权是针对 Appo其目的是让某App有权利访问某用户的信息。这里 的Token是唯一的。不可以转移到其它App上，也不可以 转到其它用户上。Session只提供一种简单的认证，即只 要有此SessionlD ,即认为有此User的全部权利。是需 要严格保密的，这个数据应该只保存在站方，不应该共享 给其它网站或者第三方App。所
5、以简单来说：如果你的用 户数据可能需要和第三方共享，或者允许第三方调用API 接口，用Token。如果永远只是自己的网站，自己的 App,用什么就无所谓了。回答问题三:三、只要关闭浏览器， session就消失了“只要关闭浏览器，session就消失了”？不对。对session来说，除非程序通知服务器删除一个 session,否则服务器会一直保留，程序一般都是在用户做退出 登陆的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器它将要关闭， 因此服务器根本不会有机会知道浏览器已经关闭，之所以会有 这种错觉，是大部分session机制都使用会话cookie来保存 ses
6、sion id,而关闭浏览器后这个session id就消失了，再次连 接服务器时也就无法找到原来的session。如果服务器设置的 cookie被保存在硬盘上，或者使用某种手段改写浏览器发出的 HTTP请求头，把原来的session id发送给服务器，则再次打开 浏览器仍然能够打开原来的session。恰恰是由于关闭浏览器不会导致session被删除，迫使服务器为 session设置了一个失效时间，当距离客户端上一次使用 session的时间超过这个失效时间时，服务器就可以以为客户端 已经停止了活动，才会把session删除以节省存储空间。HTTP cookie sessionid、toke
7、n的知识，也是比较常问的，我图解网络里还没写过，找个时间补一下。HTTP/1.0可以开启长连接吗？大佬，请问httpl.O能开启长链接 吗HTTP/1.0是可以开启长连接的，只不过它是默认关闭的，如果浏览器要开启Keep-Alive,它必须在请求的包头中添加：onnection: Keep-Alive然后当服务器收到请求，作出回应的时候，它也添加一个头在响应中:Connection: Keep-Alive这样做，连接就不会中断，而是保持连接。当客户端发送另一个请求时，它会使用 同一个连接。这一直继续到客户端或服务器端提出断开连接。从HTTP 1. 1开始，就默认是开启了 Keep-Alive,
8、如果要关闭Keep-Alive,需 要在HTTP请求的包头里添加：Connection:close现在大多数浏览器都默认是使用HTTP/1. 1,所以Keep-Alive都是默认打开的。一旦客户端和服务端达成协议，那么长连接就建立好了。源端口号（16位）目标端口号（16位）序列号（32位）确认应答号（32位）首部长度（4位）U A P R S F 保留（6位）R C S S Y IG K H T N N窗口大小（16位）交验和（16位）紧急指针（16位）选项（长度可变）数据之前有位读者的疑惑，说TCP的首部长度字段只有4位，这样算最大值就是 15,而首部长度字段是定义TCP包头的长度的，按道理
9、TCP最大的包头的长 度是：固定包头20字节+选项最长40字节=60字节。为什么可以用4位的首部长度字段来定义TCP包头的长度？我的回答：首先，首部长度字段确是定义TCP包头的长度的，但是不是你这样计算的。首部长度字段的意思是有多少个4字节，比如如果首部长度为1111（最大值）, 十进制就是15,所以首部长度字段的意思是有15个4字节，也就是15 *4 = 60oTCP时间戳回绕了怎么办？在这篇文章中：TCP是如何避免历史报文的？。提到因为TCP序列号会有回绕的 问题，所以需要用时间戳的机制来判断历史报文（简称PAWS）,然后有读者问了 这么一个问题:n 如果时间戳也回绕了怎么办时间戳的大小是
10、32 bit,所以理论上也是有回绕的可能性的。时间戳回绕的速度只与对端主机时钟频率有关。Linux以本地时钟计数（jiffies）作为时间戳的值，不同的增长时间会有不同的 问题：如果时钟计数加1需要1ms,则需要约24.8天才能同绕一半，只要报文 的生存时间小于这个值的话判断新旧数据就不会出错。如果时钟计数提高到lus加1,则回绕需要约71.58分钟才能回绕，这时 问题也不大，因为网络中旧报文几乎不可能生存超过70分钟，只是如果70分钟没 有报文收发则会有一个包越过PAWS （这种情况会比较多见，相比之下24天没有 数据传输的TCP连接少之又少），但除非这个包碰巧是序列号回绕的旧数据包而被 放
11、入接收队列（太巧了吧），否则也不会有问题；如果时钟计数提高到0.1 us加1回绕需要7分钟多一点，这时就可能 会有问题了，连接如果7分钟没有数据收发就会有一个报文越过PAWS,对于TCP 连接而言这么短的时间内没有数据交互太常见了吧！这样的话会频繁有包越过 PAWS检查，从而使得旧包混入数据中的概率大大增加；Linux在PAWS检查做了一个特殊处理，如果一个TCP连接连续24天不收发数 据则在接收第一个包时基于时间戳的PAWS会失效，也就是可以PAWS函数会放过 这个特殊的情况，认为是合法的，可以接收该数据包。tcppaws_check函数如果返回true则PAWS通static inline
12、 bool tcp_paws_check (const struct tcp_opticms_receivedif (uniikely (get_seconds ()= rx opt-ts_recent_stamp + TCP_PAWSreturn true;return false;要解决时间戳回绕的问题，可以考虑以下解决方案：1）增加时间戳的大小，由32 bit扩大到64bit这样虽然可以在能够预见的未来解决时间戳回绕的问题，但会导致新旧协议兼容性 问题，像现在的IPv4与IPv6一样2）将一个与时钟频率无关的值作为时间戳，时钟频率可以增加但时间戳的增速不 变随着时钟频率的提高，TCP在相
13、同时间内能够收发的包也会越来越多。如果时间戳 的增速不变，则会有越来越多的报文使用相同的时间戳。这种趋势到达一定程度则 时间戳就会失去意义，除非在可预见的未来这种情况不会发生。3）暂时没想到为什么重复的ACK无法判断要重传哪些数据？这篇文章你还在为TCP重传、滑动窗口、流量控制、拥塞控制发愁吗？看完图 解就不愁了经常有读者问我这个问题，为什么重复的ACK无法判断要重传哪些 数据？我的回答: 如果seq2和seq3都丢了，接收方收到seq4会回ack2,收到seq5会回ack2,seq6会回ack2。三个ack都是一样的，你怎么知道是要重传seq2,还是seq2、 seq3 呢?这三个都是重复的
14、ACK报文，seq和ack都是一样的，如下图抓包图:采集Seq + Len = T 1368TCP重复确认和快速重传的一个案例，用Wireshark分析，显示如下：3 0.000201 172.31.136.85 195.81.232.68 TCP78TCP Pup ACKeq-12313 Ack-1 Win-108、Len-1368 TSvalV332354 TSecr=225 0.000304 172.31.136.85 195.81.202.68 TCP7良(TCP Dup ACK 1#2B8766 80 ACKjSeq-l|Ackl Win-382TSval-222前Protocol
15、Lwxicth InfoSource9000 172.31.136.85 195.81.202.68 TCP2 0.000190 195.81.202.68 172.31.136.85 TCP6 0.000425 195.81.202.68 172.31.136.85 TCPWin-382 Len-0 TSval-22247173 TSecr-1332354 k-1 Win-108 Len-1368 TSval-1332354 TSecr-2278 38760 - 80 ACK Seq-1 1434 80 * 38760 fACK1 (Seg-l1434 8。 3876C ACK Seq-13
16、681 Ack-1 Win-108 Len-1368 TSval-1332354 TSecr-227 0.000435 172.31.136.85 195.81.202.68 TCP80 (ACK |Se(11| Ack-Win-382 Len-0 TSval222471434TCP Fast RetransMssion80-38ACKTAckl Win=108 |Len-136IFrame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits)Ethernet II, Src: HewlettP_a4:cl:c6 (00:16
17、:35:a4:cl:c6), Dst: All-HSRP-routers_01 (00:00:0c:07:ac:01)Transmission Control Protocol, Src Port: 38760, Dst Port: 80, Seq: 1, Ack: 1, Len: 0 Source Port: 38760Destination Port: 80Stream index: 0TCP Segment Len: 0Sequence number: 1 (relative sequence number)Sequence number (raw): 704338729- 一 .一：,
18、Next sequence number: 1(relative sequence nu-ber) | 4号 1 数,居包U月望的 FT Seq 是 1Acknowledgment number: 1(relative ack nuiiber)Acknowledgment number (raw): 13109731861011 . - Header Length: 44 bytes (11)数据包1期望的下一个数据包Seq是1,但是数据包2发送的Seq却是10945,说明收到的是乱序数据包，于是回了数据包3 ,还是同样的Seq = 1, Ack = 1,这表明是重复的ACK； 数据包4和6依
19、然是乱序的数据包，于是依然回了重复的ACK; 当对方收到三次重复的ACK后，于是就快速重传了 Seq = 1 . Len = 1368的数据包8; 当收到重传的数据包后，发现Seq = 1是期望的数据包，于是就发送了个确认收到快速重传的ACK所以，无法根据重复的ACK来判断要重传哪些数据的（注意是哪些，不是哪个）， 想要具体实现要重传哪些数据，就要使用sack这个机制（具体在图解网络已经介 绍了，这里不多说啦）。自旋锁为什么是悲观锁，而不是乐观锁？我图解系统里提到，自旋锁是悲观锁，然后有个读者说自旋锁底层是CAS实现的, 为什么不是乐观锁呢？群主自旋锁是乐观锁吧底层不是cas结构吗我的回答：乐
20、观锁是先修改同步资源，再验证有没有发生冲突。悲观锁是修改共享数据前，都要先加锁，防止竞争。CAS是乐观锁没错，但是CAS和自旋锁不同之处，自旋锁基于CAS加了 while或 者睡眠CPU的操作而产生自旋的效果，加锁失败会忙等待直到拿到锁，自旋锁是 要需要事先拿到锁才能修改数据的，所以算悲观锁。为什么10多路复用要搭配非阻塞10?这个问题在man select就有说明了。Under Linux, select () may report a socket file descriptor as ready for reading”, while nevertheless a subsequent
21、read blocks. This could for example happen whendata has arrived but upon examination has wrong checksum and is discarded. There may be other circumstances in which a file descriptor is spuriously reported asready. Thus it may be safer to use O_NONBLOCK on sockets that should not block.翻译一下就是：在Linux下
22、，selectO可能会将套接字文件描述符报告为“准备 好读取”，但随后会出现读取块。例如，当数据到达但检查时校验和 错误并被丢弃时，可能会发生这种情况。可能存在文件描述符被虚假 报告为己就绪的其他情况。因此，在不应阻塞的套接字上使用0 _NONBLOCK可能更安全。简单来说，select返回了读事件，但是该内核中不一定有数据可读，因为有可能 被内核丢弃。关于 HTTP cookie、sessionid token 的问题有位读者问下面3个问题：1 .看到网上说cookie不安全，session安全。因 为cookie存在了浏览器客户端，session存在了 服务器。劫持了cookie可以模拟用
23、户登录，但 是seesionld不也是存在cookie里的吗，那么 sessionld一样可以被劫持然后拿sessionld去模 拟登录，那这样cookie和session就没有区别了 呀，都是不安全的。2 . token是用户登录后，服务器对用户账号密码 进行了一次加密后生成的token,存储在了浏览 器。那么cookie也是用户登录后服务器返回了 set-cookie,那么我可以不可以理解为token和 cookie其实没有区别，只不过token比cookie在 服务端多进行了一次加密而已？3 .在网上看到说sessionld在浏览器关闭后就失 效了，那么再打开浏览器是不是还需要重新登 陆
24、呢？ cookie也需要重新登陆吗？由于问题比较多，我也写了一个小短文回答他的问题。回答问题一:一、cookie 和 sessionid 安全问题cookie是HTTP头部字段的一个东西，里面存放独特的身份标 识数据。如果这个身份标识数据是用户密码，那肯定不安全 呀，因为cookie是明文显示的。sessionid也是身份标识数据，只不过是由服务端生存的标识， 就是单纯的一个id,没有任何用户密码信息，即使被sessionid 知道了，也不能知道用户密码。sessionid一般都是放在 cookie中传给对方的，所以cookie就是运载sessionid的一 种方式。上面的安全层面在于会不会泄
25、漏用户登陆密码，取决于身份标 识数据存的是什么。但是Cookie安全问题在于，在JS脚本里可以用 document.cookie来读写Cookie数据，有可能会导致“跨站脚 本（XSS）攻击窃取数据。可以用以下三个方法来防止： 属性HttpOnly”会告诉浏览器，此Cookie只能通过浏览器 HTTP协议传输，禁止其他方式访问，浏览器的JS引擎就 会禁用document.cookie等一切相关的API,脚本攻击也 就无从谈起了。 另一个属性SameSite”可以防范“跨站请求伪造（XSRF） 攻击，设置成“SameSite二Strict”可以严格限定Cookie不 能随着跳转链接跨站发送，而“SameSite=Lax”则略宽松一 点，允许GET/HEAD等安全方法，但禁止POST跨站发 送。 还有一个属性叫“Secure”，表示这个Cookie仅能用 HTTPS协议加密传输，明文的HTTP协议会禁止发送。但 Cookie本身不是加密的，浏览器里还是以明文的形式存 在。