Casual Note of Computer Network
学术界TCP标准是OSI七层模型（物理层、数据链路层、网络层、传输层、会话层、表示层、应用层）、工业界是四层（网络接口层、网络层、传输层、应用层）。对于后者，各层上的数据单位分别是 物理帧 frame、网络包 packet、报文段 segment、报文段 segment。
20170605
本地环回地址（loopback）：
IPV4：127.0.0.1-127.255.255.254
IPV6：::1 (即 0000:0000:0000:0000:0000:0000:0000:0001)
20170605
TCP协议
TCP可靠的保证机制：重传机制 + 发送确认机制
客户端和服务端建立TCP连接数？
一个TCP连接由 client ip、client port、server ip、server port 四元组唯一确定，TCP报文中ip 32bit、port 16bit。假设服务端、客户端都只用一个ip（若用多个ip则连接数对应加倍）
对客户端来说，与服务端建立连接时需要本地随机分配一个端口（通常大于known port范围1024）来使用，故理论上最大 2^16 个连接。若连接用了不同的ip则最大连接数对应加倍。
对服务端来说，监听了固定的ip、port，故理论上最大连接数取决于client ip、client port的组合即 2^32 * 2^16 = 2^48个。若监听了不同的ip则最大连接数对应加倍。
实际上很难达到该值，因为每个连接在语言层面是Socket的创建，需要占用内存等资源，显然内存有限；另一方面OS对一个进程能打开的文件名描述符（一个Socket就是一个文件）有限制，Linux默认是1024，可通过 ulimit 命令修改。
TCP报文头格式
20170811
三次握手、四次挥手的相关问题（推荐参阅 CoolShell TCP连接的那些事）
20200217
2MSL的作用：（MSL，Maxmium Segment Lifetime，报文段生命最大时长）
TCP关闭过程中的TIME_WAIT状态就是client端的2MSL状态，其作用是确保server端可以收到client端发送的确认报文：最后一个确认报文可能没被server端收到，此时server端会重发fin报文，client端等待2MSL时间使得可以收到server端重发的fin报文。
RFC793 定义了MSL为2分钟，Linux设置成了30s。
20230301
注意四次挥手时四个WAIT阶段的含义区分（今日南方基金基础研发岗面试题）：三个客户端的一个服务端的
FIN-WAIT-1：客户端主动关闭连接的报文发出去 到 接收到确认报文 的时间段
FIN-WAIT-2：客户端收到上述确认报文 到 收到服务端主动发送的关闭连接报文 的时间段，这期间服务端在发送数据。
CLOSE-WAIT：服务端发出确认报文 到 主动发送关闭报文 的时间段，这期间服务端在发送数据。
TIME-WAIT：2MSL长度。
并发下 TIME_WAIT状态的连接过多导致资源浪费？可通过tcp_tw_reuse、tcp_tw_recycle两个开关来对该状态的连接复用或回收，而不是等待2MSL结束，该2参数默认是关闭的。注意，使用tcp_tw_reuse和tcp_tw_recycle来解决TIME_WAIT的问题是非常非常危险的，因为这两个参数违反了TCP协议（RFC 1122）
客户端TCP重传机制：ACK、SACK，两者不是对立的关系，而是前者为主后者为辅。详情参阅 CoolShell TCP连接的那些事
1 超时重传：时间驱动，限时内没收到ACK则重传。问题：死等超时？重传哪些？
2 快速重传：数据驱动，连续收到三次同样的ack号则重传该号的数据。主要机制。解决了死等超时问题，问题：重传哪些？
3 SACK（selective acknowledge）重传 ：服务端除了正常的ACK，还把缺失片段之后的收到的数据片段作为范围ACK发给客户端。解决了重传哪些的问题。需要客户端、服务端都支持。
Duplicated SACK：服务端一次发送的确认报文中ACK的范围和SACK的范围有重，作用：可让客户端知道是发包还是回包丢了、还是网络延迟导致包延迟到达了等。
TCP协议中的算法
重传机制：见上节
超时重传机制中的超时时间确认算法：RTO（Retransmission TimeOut）根据采样的 RTT（Round Trip Time）确定。
简单的加权移动平均：SRTT = ( α * SRTT ) + ((1- α) * RTT) 、 RTO = min [ UBOUND, max [ LBOUND, (β * SRTT) ] ] 。缺点：灵活性差；RTT计算的起点是数据报文还是重传报文发送时的时间，不管哪者在特定场景下都会有偏大或偏小的问题。
Karn / Partridge 算法：对第一种的改进，采样RTT时不考虑重传的RTT、发生重传时RTO简单粗暴地翻倍。缺点：RTO值仍不准确。
Jacobson / Karels 算法：TCP协议实现中目前使用的算法。SRTT = SRTT + α (RTT – SRTT) 、 DevRTT = (1-β)*DevRTT + β*(|RTT-SRTT|) 、 RTO= µ * SRTT + ∂ *DevRTT 。加权移动平均的问题是若RTT有大波动则因被平滑掉了很难被发现，故此算法采取RTT差异来计算SRTT而非加权移动平均。式中四个参数是调参经验值，nobody knows why, it just works…
滑动窗口算法
拥塞控制算法：慢启动、拥塞避免、拥塞控制、快速恢复
HTTP协议
2017.09.17
HTTP协议（详见：HTTP教程）
1、消息格式
1、请求消息（四部分）：
请求行（请求方法、请求路径、协议版本）
请求头（键值对列表，一个键值对一行）
回车换行
请求数据
2、响应消息（四部分）：
状态行或响应行（协议版本、状态码、状态说明）
消息报头（键值对列表，一个键值对一行）
回车换行
响应正文
2、请求方法：
3、状态码（详见：HTTP状态码）
几个典型状态码：
200：请求成功，一般用于GET与POST请求。
300：多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择。
301：永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替。
302：临时移动。临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI。
303：查看其它地址。与301类似，使用GET和POST请求查看。
304：未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源。
305：使用代理。所请求的资源必须通过代理访问。
307：临时重定向。与302类似，使用GET请求重定向。
400：坏请求。客户端请求的语法有误，服务端无法理解。
401：未认证。请求要求用户的身份认证。
403：禁止访问。服务端理解客户端的请求，但拒绝执行请求。
404：Not Found。
408：请求超时。服务端等待客户端发送的请求时间过长，超时。
500：服务器内部错误，无法完成请求。
501：服务端不支持请求的功能，无法完成请求。
502：Bad Gateway。充当网格或代理的服务器从远程服务器接收到了一个无效请求。
504：Gateway Timeout。充当网关或代理服务器未及时从远端服务器获取请求。
505：服务端HTTP版本不支持，无法完成请求。
2017.09.10
DNS使用的传输协议既可为TCP又可为UDP
20200827
关于LDNS、根DNS、二级DNS、权威DNS、DNS解析（A记录、NS记录、CNAME记录）、根DNS（13个）、根DNS镜像、根DNS管理 等的内容，参阅：https://mp.weixin.qq.com/s/JQE4iIFy5I4bDtAegZULWg
20230306
DNS查询过程，几个关键点：本地hosts、本地DNS服务器、根域名服务器（. 域名服务器）、顶级域名服务器（如 .com、.cn 域名服务器）、二级域名服务器（如 baidu.com 域名服务器）、权威域名服务器等、递归查询、迭代查询。
DNS递归查询和迭代查询的区别（详可参阅此文）：
、
从浏览器输入URL到看到最终内容，经历了什么？
可参考此文，涉及到非常多的内容，面试时可以针对其中各种点考察，主要的点有：
浏览器缓存：301等重定向，强缓存等
OS缓存：本地hosts文件
DNS解析：本地DNS服务器缓存，DNS服务器查询过程（递归或迭代）
TCP连接建立与销毁：三次握手、四次挥手（为什么是三而非二次，为什么是四而非三次，TIME_WAIT等状态的作用等）
TCP/IP协议栈数据包的封装与解析：层层向下包装、层层向上解析，数据包格式，TCP连接数考察等
HTTPS原理，HTTP协议，HTTP缓存
后端负载均衡：F5、DNS负载均衡、nginx等
页面渲染原理等
