---

网络模型和协议

参考内容：

• 《图解TCP/IP》 第1.2-1.6章节

总结

协议分层

OSI参考模型起源：OIS是一开始的时候提出的一种协议标准，ISO指定OSI之前提出了做运维通信协议设计指标的OSI参考模型，这一模型将通信协议中必要的功能分成了7层。

模型理念：每个分层都接收由它下一层所提供的特定服务，并且负责为自己的上一层提供特定的服务，上下层之间交互时遵循的约定叫做“接口”，同一层之间的交互所遵循的约定叫做“协议”。

模型要求：这个参考模型希望实现从第一层到第七层的所有模块，并将他们组合起来实现网络通信，分层可以将每个分层独立使用，即使系统中某些分层发生变化，也不会波及整个系统。

劣势：过分模块化，使处理变得更加沉重以及每个模块都不得不实现相似的处理逻辑等问题。

协议与接口：

通过对话理解分层：
两个人的对话，其实是利用电话的将音频转化为声音的接口实现的。语言、设备都可以看作是一个层，层与层之间可通过协议连接

OSI参考模型：

OSI、TCP/IP、五层：

应用层：为应用程序提供服务并规定应用程序中通信相关的细节，包括文件传输、电子邮件、远程登录等协议。

表示层：将应用处理的信息转换成适合网络传输的格式（从上往下），或将来自下一层的数据转换为上层能够处理的格式（从下往上），因此主要负责数据格式的转换。

会话层：负责建立和断开通信连接、数据分割等数据传输相关的管理。（三次、四次，数据分段，流控制？）

运输层：

• 主要任务就是负责向两台主机进程之间的通信提供通用的数据传输服务，应用进程利用该服务传送应用层报文。
• 通用的意思是不针对某一个特定的网络应用，多种应用可以通过一个运输层服务。
• 同一台主机可以同时运行多个线程，因此运输层有复用和分用的功能，所谓的复用就是指多个应用层程序可以同时使用下面的运输层服务（往外发）；分用就是把运输层收到的信息分别交付给上面应用层中的相应进程。
• 主要是使用TCP和UDP。

网络层：

• 将数据传输到目标地址，目标地址可以是多个网络通过路由器连接而成的某一个地址，因此这一层主要负责寻址和路由选择。
• 发送数据的时候，网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。
• 由于网络层使用IP协议，所以这里的分组也叫IP数据报，简称数据报。

数据链路层：

• 两台主机之间的数据传输，总是在一段一段的链路上传送的，这就需要使用专门的链路层的协议。
• 在两个相邻节点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧，在两个相邻节点间的链路上传送帧。
• 每一帧包含数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
• 在接收数据时，控制信息使接收端能够知道一个帧从哪个比特开始和到哪个比特结束。这样数据链路层在收到一个帧后，就可以从中提出数据部分，上交给网络层。
• 控制信息还能使接收端能够检测到所收到的帧中有无差错，有的话就简单丢弃这个出了差错的帧。（之后就是重新发送吧，如果错了的话）

物理层：作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异，使上层的数据链路层不必考虑网络的具体传输介质是什么。

---

OSI参考模型通信处理举例

通过发送电子邮件来举例。

七层通信的传递：
发送方从第七层到第一层按顺序传递数据，接收方从第一层到第七层由下向上传递数据。
在向下传递的时候，处理由上一层传过来的数据时可以附上当前分层协议所必须的“首部”信息；接收端对接收到的数据进行“首部”和“内容”的分离，再转发给上一分层，最终将发送端的数据恢复为原状。

首部相当于协议规范吗？

应用层：

点击发送就进入了应用层协议的处理。该协议会在前端加个首部信息，这个首部信息标明了邮件内容和收件人，B收到后分析数据首部和数据正文。

表示层：

表示层进行“统一的网络数据格式”与“某一台计算机或某一款软件特有的数据格式”之间相互转换的分层，比如邮件中的文字会被统一转换成UTF-8，UTF-16等类型的数据。
表示层和表示层之间为了识别编码格式也会附加首部信息，从而将实际传输的数据转交给下一层去处理。

会话层：

控制发送形式，比如写了五封邮件，是一次发一封共发五次还是一次发五封只发一次，决定采用何种连接方式是会话层的主要责任。
会话层也可以附加首部或者标签信息再转发给下一层，这些首部或者标签中记录着数据传送顺序的信息。

传输层：
从传输层开始，真正负责网络上具体数据的传输。

进行建立连接或断开连接的处理，在两个主机之间创建逻辑上的通道连接即是传输层的主要作用。为了确保数据达到目的地，会在通信两端的计算机之间及性能确认，如果没有到达，会负责重新发送。
比如A发了“早上好”，因为某些原因B只收到了“早上”，B收到数据后回将没有收到“早上”之后的信息的事情告诉A，这时A就会把后面的“好”重发给B，并再次确认对端是否收到。
所以传输层的一个重要作用是保证数据传输的可靠性，为了保证可靠性也会加首部来识别这一分层的数据。

网络层：

传输层用来确定是否正确接收，而数据的传输是靠网络层完成的。

如下图所示，两个主机之间会有众多数据链路，靠网络层来正确传输：

在实际发送数据时，目的地址至关重要，这个地址是进行通信的网络唯一指定的序号，基于这个地址，就可以在网络层进行数据包的发送处理，有了地址和网络层的包发送处理，就可以将数据发送到世界上任何一台互联设备。

数据链路层、物理层：

通信传输实际上是通过物理的传输介质实现的，数据链路层的作用就是在这些通过传输介质互联的设备之间进行数据处理。将数据的0、1转换为电压和脉冲光传输给物理的传输介质，相互直连的设备之间使用地址实现传输，这种地址被称为MAC地址，也可称为物理地址或硬件地址。
这一层将包含MAC地址信息的首部附加到从网络层转发过来的数据上，将其发到网络。
网络层负责将整个数据发送给最终目标地址，而数据链路层只负责发送一个分段内的数据。

网络层管着好多分段的来自下面两个层的数据，统一输送到最终目标，是这样吗？

---

HTTP介绍

参考内容：

• 《图解HTTP》 第2章节

HTTP：通常被译为超文本传输协议， 但这种译法并不严谨。 严谨的译名应该为“超文本转移协议”。

应用层：决定了向用户提供应用服务时通信的活动。FTP、DNS、HTTP都在这一层。

传输层：提供网络连接中两台计算机之间的数据传输给上层应用层。TCP、UDP。

网络层：处理网络上流动的数据包，规划到达对端的路径，并把数据包传送给对方。

链路层：用来处理连接网络的硬件部分。

流程：

• 为了传输方便，在传输层会把从应用层收到的数据（HTTP请求报文）进行分割，并在各个报文上打上标记序号及端口号后发送给网络层。
• 然后在网络层增加作为通信目的地的MAC地址后，转发给链路层。

每通过一层则增加首部。所以后面都是包含上面的的，IP里就是有TCP。

而在右边接收的时候，经过每一层都会去掉对象首部。

就是封装嘛，要把对应层的控制带上，也相当于参数传递吧。

IP传输最重要的就是IP地址和MAC地址。
IP标识节点被分配的地址，有这一个还不够吗？
IP可以和MAC配对。

通信中转的时候，会利用下一台中转设备的MAC地址来搜索下一个中转目标。

使用ARP（Address Resolution Protocol）协议，可以根据IP地址查出对应的MAC（Media Access Control Address）地址。

浏览页面过程：
真不戳

URI结构

URL：Uniform Resource Locator，统一资源定位符。

URI：

• 全拼：Uniform Resource Identifier，统一资源标识符。
• 说明：统一就是可以处理多种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式；资源的定义就是一切可以识别的任何东西；标识符表示可识别的对象，
• 格式：表面指定的URI，使用涵盖全部信息的：绝对URI、绝对URL以及相对URL。相对URL是指从浏览器中指定URI处指定的URL（就是相对路径的意思吧，前驱路径是浏览器那套资源的位置），如/image/log.gif。
  

协议方案名：方案名+冒号。
登录信息：可选项。
服务器地址：使用绝对URI，可以是DNS可解析的名字，也可以是IPv4、IPv6的地址。
服务器端口：可选项，使用服务器连接的网络端口号。
带层次的文件路径：指定服务器上的文件路径来定位特指的资源。
查询字符串：可选项，传递查询参数。
片段标识符：可选项，可以标记出已获取资源中的子资源。（像是页面？分页？）

---

HTTP：无状态协议，自身不对请求和相应之间的通信状态进行保存。但是问题在于，这样每次登录都要重新登陆，所以为了优化，提出了HTTP/1.1

HTTP/1.1：虽然也是无状态，但是引入了Cookie。

请求本文中的两种范式，要么在最上面写清楚，要么在Hsot中再补充：

GET与POST等请求指令

参考内容：

• 知乎大宽宽回答
• w3school

GET：用来请求访问已被URI识别的资源，指定的资源经服务器解析后返回相应内容。GET应该是读取，既然是读取，那么就可以对GET请求的数据做缓存，可以在浏览器本身、代理、服务器端做缓存。没副作用（也不知道这个副作用说的啥，就是说读是安全的？），具有幂等性。

POST：用来传输实体的主题，虽然使用GET也可以，但是一般用POST而不是GET传输。跟GET功能相似，目的不同。有副作用的，不幂等。（幂等就是任意执行多次均与一次执行的结果相同）。不能所以执行多次，所以也就不能缓存（要是可以缓存，那么就会返回虚假结果，因为是要往服务器里面写东西的）。

携带数据格式的区别：

• GET：要么是自己在地址栏输入的，要么是点击了html里a标签的href中的url。浏览器发出的GET只能由一个URL触发。
• POST：请求都来自表单。每次提交，表单的数据被浏览器编码到HTTP请求的body里，而这个body主要有两种格式，一种是application/x-www-form-urlencoded用来传简单的数据，大概就是key1=value1%key2=value2这样的格式；另一种是传文件，采用multipart/form-data格式，用这个传文件是因为前面那个对文件这种二进制数据非常低效。

安全性：

• 一般讲GET不如POST安全，因为GET用url，POST用body，url更容易被看到。
• 无论是url还是body，如果里面有敏感数据的话，通过中间节点，如网关、代理的时候，都会被记录下来。
• HTTP本身是明文协议，所以不管是什么都会被看到。
• 如果被用作接口的话，GET可以带body，POST也可以在url上携带数据，但绝大多数场景不是这么对应的。

GET与POST的区别总结：

• 首先是作用的区别，GET方法用来请求访问已被URI识别的资源，指定的资源经服务器解析后返回响应的内容，所以GET的主要作用是读取，既然是读取的话，就可以做缓存，可以在浏览器本身、代理，服务器端做缓存，而且操作具有幂等性，存书签或者后退刷新都没有关系；POST方法用来传输实体的主体，虽然用GET也行，但是一般用POST而不用GET，既然是传输，那么操作就不具有幂等性，不能对同一目的多次执行，也不才能做缓存，同时既不能后退也不能作为书签，每次都会触发一次提交传输。
• 其次是结构的区别，GET方法请求要么是在地址栏输入，要么是html里面的a标签的href的url，所以浏览器发出的GET只能由一个URL触发，发送数据的时候GET向URL里添加数据，但URL的长度是受限制的，最大为2048个字符，编码类型是application/x-www-form-urlencoded，只支持ASCII字符；POST的请求都来自表单，每次提交的时候，表单的数据被浏览器编码到HTTP请求的body里，body没有长度限制，这个body主要有两种格式，一种是application/x-www-form-urlencoded用来传简单的数据，大概就是key1=value1&key2=value2这样的格式；另一种是传文件，采用multipart/form-data格式，用这个传文件是因为前面那个对文件这种二进制数据非常低效。结构决定功能，所以这样看来GET适合读取，POST适合提交。如果被用作接口的话，GET可以带body，POST也可以在url上携带数据，但绝大多数场景不是这么对应的。
• 最后是安全性，一般讲GET不如POST安全，因为GET用url，POST用body，url更容易被看到，但是，无论是url还是body，如果里面有敏感数据的话，通过中间节点，如网关、代理的时候，都会被记录下来，因为HTTP本身是明文协议，所以不管是什么都会被看到，真要安全还得HTTPS。

---

REST标准：

• 定义接口方法名字一样，但是根据请求方法来执行不同功能？
• 参考

PUT：传输文件，要求在请求报文的主体中包含文件内容，然后保存到请求URI指定的位置。但是HTTP/1.1的PUT不带验证机制，存在安全问题，一般不用，如果是REST标准的，可能使用。

DELETE：按请求URI删除指定资源。跟PUT对应的，也不常用，除非有REST标准。

HEAD：和GET方法差不多，但是不要报文的主体部分，只要报文首部，用于确认URI的有效性及资源更新的日期等。

OPTIONS：查询针对请求URI指定的资源支持的方法。

TRACE：作用就是确认连接过程中发生的一系列操作，会在首部字段Max-Forward里面填入输入，每跳转一次就减一，减到0的时候就停止传输。但是不常用。（去了再回来，看看还是不是原本发送的，用来做回环检测）

CONNECT：要求用隧道协议连接代理，主要使用SSL（Secure Sockets Layer）和TLS（Transport Layer Security）协议把通信内容加密后经网络隧道传输。

能下达命令的方法：可以指定请求的资源按期望产生某种行为。

---

使用Cookie/Session的状态管理

参考内容：

• 博客

Cookie

目的：

• 不用进行多次不必要的记录。（一般存放已经登录过的用户信息，下次访问网站的时候会自动帮忙填上帮助信息）
• Cookie就是这样的一种机制。它可以弥补HTTP协议无状态的不足。在Session出现之前，基本上所有的网站都采用Cookie来跟踪会话。

性质：

• Cookie具有不可跨域名性，自己发布的只能自己用，自己也改不了别人发布的。
• 存在有效期，参数是MaxAge，修改的话要用同名覆盖，删除就是再设置一个，maxAge设为0。可以设置secure为true，这样只会在HTTPS或SSL等安全协议中传输此类Cookie。
• 那么怎么知道对什么网站发送什么cookie呢？答：Cookie是带域名的，浏览器发送时根据域名选择。

方法：

1. 客户端先给服务端发请求，然后服务器端发送响应报文回来，响应报文中会包含一个Set-Cookie的首部字段信息，通知客户端保存Cookie。
2. 客户端收到带有Set-Cookie的请求后，会保存到本地，下次给服务端发消息的时候会根据域名找到Cookie，带上Cookie信息。
3. 服务端收到Cookie后，会对比服务端上的记录，最后得到之前的状态信息。

响应的报文：

csrf攻击：

---

Session

作用：服务端使用的记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力，类似服务器建立客户档案，来的时候自己检查一下。（登陆一次网站后访问网站的其他页面不需要重新登录）

创建时间：Session对象是在客户端第一次请求服务器的时候创建的。

结构：Session结构是HashTable。
使用：

• Session的正常运行需要客户端的支持，因为Session需要使用Cookie作为识别标志。因为HTTP是无状态的（不知道从哪来），所以Session不能根据HTTP连接来判断是否为同一客户，所以服务端向客户端发送一个生成Cookie的相应，值为JSessionID，然后根据这个Cookie判断是否为同一用户。
• 这个Cookie为服务器自动生成的，maxAge属性一般是-1，表示仅当前浏览器有效，并且各个浏览器窗口间不共享，关闭浏览器就失效。当多个客户端执行程序时，服务器会保存多个客户端的Session。Session机制决定了当前客户只会获取到自己的Session，而不会获取到别人的Session。各个客户的Session彼此独立，互不可见。
• 所以同一个机器的两个浏览器访问服务器时，会生成两个不同的Session，同一浏览器的子窗口会共享父窗口的Cookie，因此会共享一个Session。
• 服务器一般把Session放在内存里。Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。

JSESSIONID创建：

消失时间：Session也有超时时间，如果超过了时间没访问，Session就失效了；或者说所有的浏览窗口关闭了，Session也就失效了。

不能使用Cookie时的做法：

• 方法：URL地址重写。
• 原理：将该用户Session的id信息重写到URL地址中，服务器能够解析重写后URL获取Session的id。（所以这个带Session的URL是客户端发过来的？那是客户端生成的？）（应该还是根据第一次访问服务器后，服务器返回的响应报文决定的。）

如何判断是否支持Cookie：TOMCAT判断是否支持Cookie方式：尽管客户端可能会支持Cookie，但是由于第一次请求时不会携带任何Cookie，所以URL地址重写后会带有jsessionid，第二次有Cookie了，URL地址重写后就不会带有jsessionid。
（感觉不对，第一次怎么知道JESSSIONID）

---

Cookie和Session对比

Cookie和Session区别总结：

1. 位置：Cookie数据存在客户的浏览器上，Session数据放在服务器上。
2. 生命周期：Cookie是预先设置的生存周期，或永久的保存于本地的文件，Session是IE启动到IE关闭，浏览器页面一关，session就消失了，因为Session信息是存放在server端，但session id是存放在客户端的。
3. 安全性：cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗，考虑到安全应当使用session。
4. 大小与存放内容格式：单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie，而且只能存放ASCII字符串，通过编码的方式存储为Unicode字符或者二进制数据；Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型。
5. 性能考虑：session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。

安全性说明：

• cookie在客户端上，对所有用户可见，不安全，Session存储在服务器上，客户端看不到。但是还是有拦截，如果获取了sessionid，使用特殊的浏览器伪造该用户的请求也能够成功。
• cookie欺骗两个条件，一个是cookie文件，一个是index.dat文件，记录了cookie文件的创建时间、是否修改等信息，这两个都要做好。

---

HTTP报文

内容：HTTP大致可以分为报文首部和报文主体两块，通常不一定要有报文主体。

请求报文（上）与响应报文（下）结构：

请求行、状态行、报文主体的实例：

• 请求行：包含用于请求的方法，请求URI和HTTP版本。
• 状态行：包含表明响应结果的状态码，原因短语和HTTP版本。
• 首部字段：包含表示请求和响应的各种条件和属性的各类首部。
• 其他：可能包含HTTP的RFC里未定义的首部（Cookie等）。

报文主体和实体主体的差异：

• 报文（message）：是HTTP通信中的基本单位，由8位组字节流组成，通过HTTP通信传输。
• 实体（entity）：作为请求或响应的有效荷载数据被传输，内容由实体首部和实体主体组成。（所以这一块在哪呢？看下面）
• HTTP报文的主体用于传输实体主体，通常情况下，报文主体等于实体主体，只有当传输中进行编码操作时，实体主体的内容发生变化，才导致它和报文主体产生差异。

---

HTTP首部字段

结构：由首部字段名和字段值构成，中间用分号隔开，如Context-Type: text/html，可以对应多个值Keep-Alive: timeout=15, max=100。

keep-Alive：本次HTTP请求结束后不需要关闭TCP连接。

通用首部字段（General Header Fields）：

请求首部字段（Request Header Fields）
从客户端向服务端发送请求的时候使用的首部，补充了请求的附加内容、客户端信息、相应内容相关优先级等信息。

响应首部字段（Response Header Fields）：
从服务端向客户端返回响应报文时使用的首部，补充了响应的附加内容。

实体首部字段（Entity Header Fields）：
针对请求报文和响应报文的实体部分使用的首部，补充了资源内容更新时间等和实体相关的信息。

---

HTTPS

参考内容：

• 《图解HTTP》 第7章节

HTTP缺点

1. 通信使用明文，内容可能被窃听：

• 问题：
  • 按照TCP/IP协议族的工作机制，通信内容在所有通信线路上都有可能遭到窥视。
  • 即使可以对通信加密，但是加密处理后的报文信息本身还是能被看到。
  • 别人可以对互联网上流动的数据包收集，然后获取HTTP协议的请求和响应的内容，并对其进行解析。
• 解决方法：通信加密，借助SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security）的组合使用，加密HTTP，HTTP和SSL结合就是HPPTS（HTTP Secure，超文本传输安全协议）。
• 无效的解决方法：对报文主体加密，但是这样报文主体的内容还是会被查看到并被篡改。

2. 不验证通信方的身份，因此可能遭遇伪装：

• 问题：
  • HTTP协议中的请求和响应不会对通信方进行确认，即无法确定对方是不是真的自己想要的，服务器只要接受到请求就会响应。
  • 因为照单全收，所以无法阻止海量请求下的DoS攻击（Denial of Service，拒绝服务攻击）。
  • 无法确定正在通信的对方是否具有访问权限。
• 解决方法：查看对手的证书，SSL提供了证书的手段，用于确认方，证书由值得信任的第三方机构颁发，而且伪造起来异常困难。（后面会详细说证书）

3. 无法证明报文的完整性，所以有可能已遭篡改：

• 问题：
  • 接收的内容可能有误，内容被篡改，这种请求/响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）。
• 解决方法：求助于HTTPS。
• 不好用的解决方法：使用MD5和SHA-1等散列值校验方法来确认文件中的数字签名，但是这个得用户自己下载验证文件PGP，而且MD5和PGP本身也可能被改写。

---

HTTPS加密/对称与非对称

HTTPS介绍：之前是HTTP直接和TCP通信，当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。

共享**加密（Common key crypto system）/对称加密：

• 方法：加密和解密都只用一个**。
• 问题：用共享**加密的时候要把**也发给对方，如果被监听了就完蛋了，加密也没有，那要是没监听加不加密也无所谓。

公开**加密（Public-key cryptography）/非对称加密：

• 方法（SSL用的这个）：
  • 两把**，一个是公开**，一个是私有**，私有**不能让任何人知道，而公开**可以随意公开。
  • 发送密文的一方使用对方的公开**进行加密，对方收到后，使用自己的私有**进行解密。
• 问题：
  • 无法判断你这个公开**真假，是不是真的来自我想要的地方，可能在途中被篡改替换掉了。
  • 速度比较慢。

HTTPS采用混合加密机制：

• 方法：
  • HTTPS采用的是共享**加密和公开**加密两者并用的混合加密。
  • 共有三个**，一个是用来做共享**加密的，另外两个是给共享**加密的公开和私有**。
  • 在交换**环节使用公开**的方法对共享**加密，之后通信交换报文阶段使用私有**解析出来的共享**，就建立之前使用公开比较耗时，但只有一次，后面使用共享就很快。

---

数字证书/数字签名

https://www.cnblogs.com/androidsuperman/p/7062122.html
https://www.zhihu.com/question/52493697

数字证书认证机构（CA，Certificate Authority）：

• 介绍：值得信赖的第三方机构，手里有一个公开**和一个私有**。
• 作用：服务器的运营人员向CA提出公开**的申请，CA判明这个申请者身份后，会用自己的私钥对这个申请的公开**做处理，即做数字签名，然后分配这个已经签名的公开**，并将该公开**放入公钥证书后绑定在一起。（分配是什么意思？）

使用流程：

• 服务器把这个公钥证书发送给客户端（这个发送并不安全），公钥证书也可以叫做数字证书或直接称为证书。
• 客户端可以使用CA的公开**，对证书上的签名进行验证，一旦通过就可以知道这个公开**是真的。

CA公开**的问题：
安全转交这个公开**也是很困难的，所以多数浏览器开发商会直接在内部植入常用的认证机关的**。

(数字证书是不是说，CA公开**+数字签名（CA私有+申请公开**） = true？ 验证后得到什么？)

HTTPS通信：

SSL加密：

带SSL加密的连接过程：

1. 客户端发送Client Hello，报文中包含支持的SSL版本和加密列表。
2. 服务端收到后，返回个Server Hello，报文中包含支持的SSL版本和加密列表，这个加密列表是在客户端发过来的加密列表里面筛选出来的。
3. 然后服务端发Certificate报文，里面包含公开**证书。
4. 服务端继续发送Server Hello Done报文，告诉客户端SSL第一阶段握手结束。
5. 客户端收到证书后，使用数字证书的公开**解析，验证服务端的身份并获取公开**，然后发送Client Key Exchange报文，里面包含公开**加密的一段随机密码串。
6. 客户端还会发送个Change，说明以后都用新生成的随机密码串加密发送的报文。
7. 客户端继续发送Finished，这段报文使用新**加密的，包含之前发送的全部报文的校验值。
8. 服务端收到后用私有**解析密码，并给客户端发送个Change，以后也用新**加密报文。
9. 服务端给客户端也发送Finished。
10. 交换Finished之后，SSL握手阶段结束，以后都会用新的**通信，开始进入应用层协议，发送HTTP请求。
11. 应用层通信协议，发送HTTP请求，这里会带上叫MAC（Message Auth Code）的报文摘要，可以检测报文是否被篡改。
12. 关闭的时候客户端发送close_notify报文，在发送TCP的FIN来关闭TCP的连接。

区别总结

---

HTTP1.0/1.1/2.0区别

参考内容：

• 简书
• 缓存策略 1
• 缓存策略 2
• 知乎

HTTP/1.0和HTTP/1.1的区别：

1. 长/短连接：在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接；每次连接的建立与断开都需要三次握手和四次挥手的开销，如果每个请求都这样的话，开销很大；HTTP/1.1默认是使用长连接，持续连接有非流水线方式和流水线方式，流水线方式是客户端在收到HTTP的响应报文之前就能接着发送新的请求报文（不用等发送的确认回来就能继续），非流水线方式是客户端在收到前一个响应后才能发送下一个请求（收到返回确认后才能动，比较慢）。
2. 错误状态响应码：在HTTP/1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性删除。
3. 缓存处理：在HTTP/1.0中主要使用header里的If-Modified-Since（判断最后修改时间是否一致）、Expires（本地副本缓存过期时间）来作为缓存判断的标准；HTTP/1.1则引入了更多的缓存控制策略，例如Entity tag（版本号校验）、If-Unmodified-Since(从某个时间点算起，文件没有被修改)、If-Match、If-None-Match（这两个是因为只用修改时间作为判断依据还不够，可能ABA，这样也不用改）等更多可供选择的缓存头来控制缓存策略。

HTTP/2.0和HTTP/1.X相比的新特性：

1. 新的二进制格式（Binary Format）：
   • HTT1.x的解析式基于文本的，文本存在缺陷，使用二进制更方便健壮。（POST不是能二进制吗？）
   • 在应用层（HTTP/2.0）和传输层（TCP/UDP）之间加了个二进制分帧层。这个层中，会把所有的传输信息分割成更小的信息和帧，并对它们采用二进制格式的编码，其中HTTP/1.x的首部信息会封装到HEADERs frame，而响应的Request Body会封装到DATA frame里面。
   • 
2. 多路复用（MultiPlexing）：
   • 即连接共享，每一个Request都是连接共享机制的。一个Request对应一个id，这样一个连接上可以有多个Request，多个Request可以随机混杂在一起，接收方根据Request的id将Reuqest再归属到各自不同的服务端请求中。（感觉似曾相识啊？跟运输层的多路复用挺像？？）
   • 比较：HTTP/1.x的TCP的慢启动会限制开始时连接的速度，防止爆掉，HTTP/2.0让所有的数据流公用一个链接，可以更有效的使用TCP连接，让高宽带也能真正的服务于HTTP的性能提升。
3. Header压缩：HTTP1.x的Hedaer带有大量信息，每次都要重复发送，HTTP2.0使用encoder来减少需要传输的Header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。
4. 服务端推送（server push）：
   • 服务端可以对客户端的一个请求发送多个响应；服务端推送能把客户端所需要的资源伴随着index.html一起发送到客户端，省去了客户端重复请求的步骤。正因为没有发起请求，建立连接等操作，所以静态资源通过服务端推送的方式可以极大地提升速度。
   • 

其他，了解一下：
为什么慢启动会对拷贝海量小文件的需求造成重大性能损失呢？
举个简单的例子，我们对每个文件都采用独立的TCP连接来传输（循环使用scp拷贝就是这个例子的实际场景，很常见的用法）。那么工作过程应该是每传输一个文件就建立一个连接，然后连接处于慢启动阶段，传输小文件，每个小文件几乎都处于独立连接的慢启动阶段被传输，这样传输过程中所用的TCP包的总量就会增多。更细致的说一说这个事，如果在慢启动传输过程中传输小文件，可能需要2_{3个小包，而在一个已经完成慢启动的TCP通道中，我们传输这个文件只需要1个大包。网络拷贝文件的时间基本上全部消耗在网络传输的过程中（发送数据等对端ACK，ACK确认归来继续再发，这样的数据来回交互比较本机的文件读写非常耗时间），撇开三次握手和四次握手那些包，粗略来说，慢启动阶段传输这些文件所用的包的数量是高速通道传输这些文件的包的数目的2}3倍，那么时间上应该也是2~3倍的关系！如果文件的量足够大，这个总时间就会被放大到需求难以忍受的地步。

---

HTTP状态码

状态码类别：

304：跟缓存有关，发了个带条件的GET请求，但是数据并没有发生变化，就返回304。

---

HTTP缓存

参考内容：

• 《图解HTTP》
• Segmentfault

目的：减少源服务器的压力，也节省了通信流量和通信时间。

缓存位置：缓存服务器和本地，这两个都能存放一部分资源，而且也会给缓存设置有效期，过期了就更新。

---

HTTP长连接短连接

参考内容：

• 博客

HTTP协议和TCP/IP协议的关系：

• HTTP的长连接和短链接本质上是TCP长连接和短连接。
• HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。
• HTTP协议是无状态的，指的是协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态，也就是说，打开一个服务器上的网页和上次打开这个服务器上的网页之间没有任何联系。

短连接：

• 使用：HTTP/1.0默认使用短连接。
• 工作方式：
  • 客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。
  • 当客户端浏览器访问的某个HTML或其它类型的Web页面中有其他的Web资源（如JS文件、图像文件、CSS文件），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
  • （是不是说点了网页的其他东西跳转的时候就会重新建立连接？）

长连接：

• 使用：HTTP/1.1默认使用连接，用以保持连接特性。
• 代码：会在响应头加入Connection:keep-alive。
• 工作方式：
  • 在使用长连接的情况下，当一个网页打开完成之后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
  • Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件中设置这个时间。
  • 实现长连接需要客户端和服务短都支持长连接。

---

TCP和UDP的区别

参考内容：

• 《图解TCP/IP》 第6.1、6.3、6.4章节

TCP：Transmission Control Protocol
UDP：User Datagram Protocol

TCP/IP分层：

• 分层：应用层、传输层、网络层和数据链路层。
• 好处：把各层接口规划好，就能独自*改动了。

传输层的作用

TCP/IP中两个具有代表性的传输层协议：

• TCP：提供可靠的通信传输。
• UDP：常被用于让广播和细节控制交给应用的通信传输。

协议字段：IP首部有一个协议字段，用来标记网络层的上一层所采用的是哪一种传输层协议，根据这个就可以识别出IP传输的是TCP还是UDP的内容。

端口号：当传输层往应用层传数据的时候，需要知道传递给哪个应用程序，而使用端口号就可以识别出要处理的具体应用程序。

通信处理：上面提到的应用程序，就是用来进行TCP/IP应用协议的处理的东西，TCP/IP的众多应用协议大多以客户端/服务端的形式运行。

HTTP连接请求：

守护进程：

• 这些服务端的程序在UNIX系统当中叫做守护进程。
• UNIX中不需要将这些守护进程都启动，只需要启动一个可以代表他们接收请求的inetd服务程序就行。
• 该超级守护进程受到客户端请求后会fork新的进程并转换exec为各个守护进程。

---

TCP与UDP

传输方式	可靠性	连接型	特点	使用场景	首部字节
TCP	提供	面向有连接型，传输前必须先建立连接，传输后释放连接	实行“顺序控制”或“重发控制”机制，还具有“流控制”、“拥塞控制”、提高网络利用率等功能 ，但开销比较大，数据单元的首部比较大，还要占用许多处理机资源	适用于对精度有需求的情况 ，如文件传输、邮件发送、远程登录等	20-60
UDP	不提供	面向无连接型，实现不需要建立连接，远程主机收到报文后也不需要给出任何确认	细微的处理会交给上层应用完成，虽然可以确保发送消息的大小，但不能保证消息一定会到达，所以应用需要根据自己的需要进行重发处理，开销比较小	适用于对高速传输和实时性有较高要求的通信或广播通信，多播和广播通信用的这个，如QQ语音、直播等	8

丢包：在实时传送动画或声音时，途中一部分网络的丢包可能导致画面或声音的短暂停顿或出现混乱，但实际使用中没什么大碍。

面向有连接型：在发送数据之前，需要在收发主机之间连接一条通信线路。
就像打电话，只有对面接了电话才能真正通话，对面挂断后就像切断电源，所以这种方式下，在通信传输前后，专门进行建立和断开连接的处理。

面向无连接型：不要求建立和断开连接，发送端可于任何时候*发送数据，接收端也永远不知道自己会在何时从哪里收到数据，所以接收端要时常确认是否收到了数据。
就像寄快递的时候，不需要确认详细地址是否存在，也不需要确认收件人是否可以收到就可以发。

Socket：使用TCP或UDP通信时，会广泛用到Socket的API，应用程序可以利用Socket来设置对端的IP地址、端口号、实现数据的发送与接收。

UDP详细特点：

• 是一个在收到应用程序发来的数据的那一刻，立即按照原样发送到网络上的一种机制。（不经过下面的数据链路吗？）
• 因为没有流量控制，所以无法避免网络拥堵的情况下出现网络拥塞的行为。
• 因为没有重发、顺序控制，所以即使丢包了也不重发，即使顺序乱掉了也不纠正。
• 所以上面没有的细节控制，都要通过UDP的应用程序来处理，也就是说使用UDP的时候程序员要充分考虑上层协议类型并制定相应的应用程序。
• 常用的方面：
  • 包总量较少的通信（DNS、SNMP等）。
  • 视频、音频等多媒体通信（即时通信）。
  • 限定于LAN等特定网络中的应用通信。
  • 广播通信（广播、多播）。

---

TCP 协议如何保证可靠传输

参考内容：

• 《图解TCP/IP》 第6.4章节

保证可靠性面临的问题：数据的破坏、丢包、重复、分片顺序混乱等。

保证可靠性的方法：TCP通过检验和、***、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。

总体回答：

1. 应用数据被分割成TCP认为最适合发送的数据块。
2. TCP给每个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
3. 校验和：TCP将保持它首部和数据的校验和，这是一个端到端的校验和，目的是检测数据在传输过程中的任何变化。如果收到段的校验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
4. TCP的接收端会丢弃重复的数据。
5. 流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP接收端只允许发送端发送接收端缓冲区能接纳的数据，当接收方来不及处理发送方的数据时，可以提示发送方降低发送的速率，防止包丢失。TCP通过滑动窗口实现流量控制。
6. 拥塞控制：当网络拥塞时，减少数据的发送。
7. ARQ协议：也是为了实现可靠传输的，基本原理就是每发完一个分组就停止发送，等待对方确认，在收到确认后再发出下一个分组。
8. 超时重传：当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段，如果不能及时收到一个确认，将重发这个报文段。

通过***与确认应答提高可靠性

确认应答：

• 当发送端的数据到达接收主机时，接收端主机会返回一个已经收到消息的通知，这个消息叫做确认应答（ACK）。
• 如果没收到就返回一个否定的确认应答（NACK）。

等待确认应答与重发：发送端传出数据后会等待对端的确认应答，如果等待超过一段时间还没有收到的话，就会重发数据。

收不到确认应答的两种情况：

1. 发送端的消息没发过去：这种情况重发一遍就行了。
2. 接收端返回的确认应答丢包了：这种情况需要好好处理，因为接收端为了对上层应用提供可靠的传输，必须放弃重复的数据包。

***解决重复接收问题：

• ***：是按照顺序给发送数据的每一个字节（每个8位）都标记上号码的编号，依次加一，但初始值不是0，是在建立连接后随机生成的。
• 接收端操作：查询接收数据TCP首部中的***和数据长度，将自己下一步应该接收的序号作为确认应答返回回去，同时保存下来，如果下次接收的序号不是应得的，就继续返回应得的。
• 注意：TCP的数据长度不是写在TCP首部里面的，是实际通信中求得的：IP首部中的数据包长度 - IP首部中TCP首部长度。

情况1：

情况2：

---

重发超时如何确定/自动重传请求ARQ

目标：找到一个能保证“确认应答一定能在这个时间内返回”的时间。

方法：

• TCP在每次发包时都会计算往返时间及其偏差，然后等待时间 = 往返时间 + 偏差 + 一个稍大的值。
• Unix和Windows系统中，超时以0.5秒为控制单位，所以重发超时都是0.5秒的整数倍，初次设置一般为6秒左右。
• 重发后若还是收不到确认回应，则再次发送，同时等待确认时间会以2倍、4倍的指数函数延长，但达到一定重发次数后，如果还没收到，就会判断网络或对端主机产生了异常，强制关闭连接，并且通知应用通信异常强行终止。

加偏差原因：因为网络环境不同可能导致往返时间产生大幅度的摇摆，而出现这种情况是因为数据包的分段是经过不同线路到达的，所以TCP/IP的目的是即使在这种情况下也要进行控制。

---

连接管理/三次握手四次挥手

参考内容：

• 知乎

连接建立过程：

1. 客户端通过TCP首部发送一个SYN包作为建立连接的请求，同时等待ACK。
2. 对端发送ACK的同时也发送一个SYN，请求建立连接。
3. 客户端对服务端发送ACK，连接建立完成，可以发送数据了。

连接切断过程：

1. 客户端先发送FIN包请求切断。
2. 服务端返回ACK。
3. 服务端发送FIN。
4. 客户端发送ACK到服务端，连接解除。

为什么要传回SYN：
接收端传回发送端所发送的SYN就是为了告诉发送端，我收到的信息确实就是你发送的信号了。
（SYN的作用不是建立连接吗？）

传了SYN，为啥还要穿ACK？：就是为什么要第三次握手。

为什么三次握手:

• 防止失效的连接请求到达服务器,从而导致服务器错误的打开连接.
• 客户端发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到服务器端发回的连接确认。客户端等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达服务器，如果不进行三次握手，那么服务器就会打开两个连接。如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，因此就不会再次打开连接。（SYN也是带***的，根据ACK带的回应***知道是哪个连接起来了）。
• （没有第三次握手服务端无法知道自己发送正常）

为什么不是两次握手：
是不是两次有可能服务端到客户端的时候直接丢包啊。对，但是要从两方面考虑，一方面是客户端数据没能发送过去，另一方面是服务端数据没能发送过去。
（采用两次握手，那么若Client向Server发起的包A1如果在传输链路上遇到zhi的故障，导致传输到Server的时间相当滞后，在这个时间段由于Client没有收到Server的对于包A1的确认，那么就会重传一个包A2，假设服务器正常收到了A2的包，然后返回确认B2包。由于没有第三次握手，这个时候Client和Server已经建立连接了。再假设A1包随后在链路中传到了Server，这个时候Server又会返回B1包确认，但是由于Client已经清除了A1包，所以Client会丢弃掉这个确认包，但是Server会保持这个相当于“僵尸”的连接。（SYN也是带***的，根据ACK带的回应***知道是哪个连接起来了，Server接到了A2相关的包，就会进入确定状态了）
所以采用两次握手，有可能会浪费Server的网络资源）

为什么是四次挥手,不是三次挥手？：

• 建立连接的时候，Server把响应客户端的请求和请求客户端的确认放在一起发送给客户端了，即第二次握手时有SYN+ACK。
• 断开连接的时候，是客户端对服务端单方面断开，只是说明该方向数据已传输完毕，而另一个方向或许还有数据，所以得等到另一个方向数据也全部传输完成后，才能执行第三次挥手（客户端先收到了ACK，等服务端传输完了之后，才收到服务端传来的FIN）。

---

TCP以段为单位发送数据

最大消息长度（MSS）：Maximum Segment Size，建立TCP连接的同时，也可以确定发送数据包的单位。最理想的情况是，MSS正好是IP中不会被分片处理的最大数据长度。

为什么要分片：不同的链路类型能够支持的最大传输单元值（MTU: Maxitum Transmission Unit）主要是由相关RFC文档规定的，常见的以太网链路的MTU值为1500，如果需要转发的IP报文超出其转发接口的MTU值，则在转发该报文之前，需要将其分片，分为多个适合于该链路类型传输的报文，这些分片报文在到达接收方的时候，由接收方完成重组。

使用：TCP传输大量数据时，是以MMS的大小将数据进行分割发送，重新发送时也是以MSS为单位。

计算MSS：是在三次握手的时候，在两端主机之间被计算得出的，两端主机在发出建立连接的请求时，会在TCP首部中写入MSS选项，告诉对方自己的接口能够适应的MSS大小，然后在两者之间选择一个较小的值投入使用。

---

窗口控制与重发控制/连续ARQ协议

问题：TCP以1个段为单位，每发一个段进行一次确认应答的处理，但是这样很慢，很多时间消耗在往返上了。

解决方法：确认问答不再以每个分段进行，而是以更大的单位进行确认，这样转发时间会被大幅度的缩短。（跟Redis的Pipeline很像，减少的是什么来着?IO还是网卡通信？）。

窗口：窗口大小就是指无需等待确认应答就可以继续发送数据的最大值，这个机制的实现使用了大量的缓冲区。

滑动窗口控制：收到全部的ACK后就可以把数据从缓冲区清除，然后将窗口滑动到ACK中的***的位置。

窗口使用的问题：

1. 客户端发给服务端的信息丢了。
2. 服务端返回的ACK丢了。

客户端信息丢失问题（高速重发机制）：

• 丢了就要重发，这就说明在确定某端数据都被ACK之前，数据都要保存在缓冲区不能清除。
• 因为连续发多条，如果中间丢失，后面的发送出去的***就会和服务端想要的***对不上，这是服务端就会返回想要的***的ACK，每来一个不对的就重复一次。
• 但是，虽然返回的是想要的***，可还是把传过来的数据接收了放到缓冲区中，这样等后面确实的重发后就直接连上了，不需要再从缺失的地方都重来一次了，具体看下面的图。
• 当客户端主机连续3次受到同一个确认应答的时候，就会对缺失的数据进行重发。

连续ARQ协议：
还有个Go-Back-N问题，跟高速重发机制不一样，就是如果分组中某一个断掉了，就从断了的地方重来，客户端要重新发送断的及断的之后的数据包。

服务端返回的ACK丢失问题：
丢了某些ACK也没有关系，可以检查后面的ACK，如果后面的ACK对了前面发送的数据就不会丢，为什么可以看上面的问题。

---

流控制

（前面的段和窗口管的是怎么传输，流管的是什么时候传输）
问题：接收端可能接收到没用的数据，也可能处理它花了很多时间导致高负荷无法接收其他数据，如果接下来有用的数据传进来了，接收端因为无法处理而丢弃，就会触发重发机制，从而浪费了网络流量。

流控制功能：TCP提供的一种机制，可以让发送端根据接收端的实际接受能力控制发送的数量。

具体操作：

• 接收端向发送端通知字节可以接收数据的大小，于是发送端会发送不超过这个限度的数据，而这个大小限度就是窗口大小。
• TCP首部中，专门有一个字段用来通知窗口大小，接收端可以把自己可以接受的缓冲区大小放到这个字段中，然后传递给发送端，这个数值越大，说明网络的吞吐量越高。
• 接收端的缓冲区面临数溢出时，窗口的大小会被设置成一个更小的值通知给发送端，从而控制数据发送量。
• 缓冲区满后，就会停止接收数据，在收到来自接收端的窗口更新的通知后才能继续，但如果这个通知丢了，可能导致无法继续通信，所以发送端时不时会发送一个叫做窗口探测的数据段，此数据段仅包含一个字节以获取最新的窗口大小信息。

---

拥塞控制

和流控制的区别：

• 拥塞控制是一个全局性的过程，涉及到所有主机、所有路由器，以及与降低网络传输性能有关的所有因素。
• 流量控制往往是点对点通信量的控制，是个端到端的问题，流量控制要做的就是抑制发送端发送数据的速率，以便接收端来得及接收。

问题：如果通信刚开始就发送大量数据，可能会引发其他问题，而且在拥堵的时候，如果突然发送一个较大的数据，极有可能导致整个网络瘫痪。

解决方法：通过慢启动对发送的数据量进行控制，定义一个“拥塞窗口”概念，用来调节发送的数据量。

慢启动：

• 开始的时候，将拥塞窗口的大小设置为1个数据段（MSS），之后每收到一个ACK，拥塞窗口的值就加1。
• 发送数据包之后，将拥塞窗口的大小和接收端主机通知的窗口大小作比较，然后取其中的较小值，发送比这还小的数据量。
• 如果重发采用的是超时机制，那么拥塞窗口的初始值可以设为1，再慢慢修正。
• 但是拥塞窗口的数量是指数增长（每次的窗口变多，每次的增量就变多），所以引入慢启动阈值概念。

慢启动阈值：

• 一旦窗口数量超过阈值，每次收到ACK后的窗口的放大比例（应该是加法，乘法就太大了）：（一个数据段的字节数 x 一个数据段的字节数 / 拥塞窗口的字节数）
• TCP刚开始的时候没有设置慢启动阈值，此时阈值就是窗口的最大值，当经历了超时重发后，会将阈值设置为当时拥塞窗口一半的大小。
• 重复确认应答后，阈值大小也会变化，变成被设置时窗口大小的一般，然后窗口大小本身变成更改后的阈值+3个数据段的大小。

快重传与快恢复：上面的重发控制。

---

首部格式

参考内容：

• 《图解TCP/IP》第4.7、4.8、6.6、6.4章节

IPv4

IP首部包含内容：用于IP协议进行发包控制时所有的必要信息。

版本：

• 大小：4 Bit。
• 功能：表示IP首部的版本号。
• 版本号变化：未被广泛正式使用的版本也会有编号，所以经过一些列实验过程，直接到了IPv6。

首部长度（IHL：Internet Header Length）：

• 大小：4 Bit。
• 功能：表明IP首部的大小，单位是4字节，也就是32 Bit，根据上面的图可以知道，不存在可选项的时候，有5行，也就是5个单位，IP首部大小为4 x 5 = 20字节，如果存在的话就是4 x 6 = 24字节。

区分服务（TOS：Type Of Service）：

• 大小：8 Bit。
• 功能：表明服务质量，值应该由应用指定，但实现TOS控制很复杂，所以几乎没人用，还有人提出本身再分为DSCP（Differential Services Codepoiint，差分服务代码点）和ECN（Explicit Congestion Notification，显式拥塞通告）的建议。

总长度：

• 大小：16 Bit。
• 功能：表示IP首部与数据部分合起来的字节数，所以最大程度就是65535字节，超出就要分片。

标识：

• 大小：16 Bit。
• 功能：用于分片重组，同一个分片的标识值相同，不同分片的标识值不同；但是相同的标识不一定是同一个分片，除了ID，目标地址、源地址、协议也要相同，才会被认为是相同的分片。

标志：

• 大小：3 Bit。
• 功能：表示包被分片的相关信息。

片偏移（FO：Fragment Offset）：

• 大小：13 Bit。
• 功能：标识被分片的每一个分段相对于原始数据的位置。13位，所以可以表示 2 13 = 8192 2^{13}=8192 213=8192个相对位置，每个位置表示8字节，所以最大可以表示8 x 8192 = 65535字节的位置。（每个位置表示8字节是怎么确定的？每个片段最大8字节？）

生存时间（TTL：Time To Live）：

• 大小：8 Bit。
• 功能：以秒为单位记录当前的包在网络上应该生存的期限，但实际中就是能中转多少个路由器的意思，每经过一个路由器，TTL会减少1，直到变成0则丢弃该包。因为是8位，所以中转路由的次数不会超过256个，这样可以避免IP包在网络内无限传递的问题。

协议：

• 大小：8 Bit。
• 功能：表示IP首部的下一个首部隶属于哪个协议。

首部校验和（Header Checksum）：

• 大小：16 Bit。
• 功能：只校验数据报的首部，不校验数据部分，主要用来确保IP数据不会被破坏。
• 方法：首先将该校验和的所有位置设为0，然后以16 Bit为单位划分IP首部（前面的那些），并用1补数计算所有16位字的和，最后将得到的这个和的1补数赋值给首部校验和字段。（每16个算一个值，然后对每个值处理，处理完了加在一起）。

源地址：

• 大小：32 Bit。
• 功能：表示发送端IP地址。

目标地址：

• 大小：32 Bit。
• 功能：表示接收端IP地址。

可选项：

• 大小：长度可变。
• 功能：通常只在进行实验或诊断时使用，包含以下信息：安全级别、源路径、路径记录、时间戳。

填充物：

• 大小：根据可选项大小而定。
• 功能：如果有可选项的话，首部长度可能不是32 Bit的整数倍（注意上面首部长度，每个单位4字节，也就是32 Bit），所以向字段填充0，调整为32 Bit的整数倍。

数据：

• 大小：看数据量。
• 功能：存入数据，同时将IP上层协议的首部也作为数据进行处理。

---

IPv6

省略了首部校验和字段：

• 目的：为了减轻路由器的负担。
• 原理：TCP和UDP在做校验和计算的时候使用伪首部，所以可以验证IP地址或协议是否正确，因此即使IP层无法提供可靠传输，在TCP或UDP层也可以提供可靠传输的服务。

版本：

• 大小：4 Bit。
• 功能：版本号，此处为6。

通信量类（Traffic Class）：

• 大小：8 Bit。
• 功能：相当于IPv4的TOS，本来打算在IPv4里删掉TOS，但是出于研究考虑还是保留了。

流标号（Flow Label）：

• 大小：20 Bit。
• 功能：
  • 准备用于服务质量（QoS：Quality Of Service）控制，不使用QoS时每一位可以全部设置为0。
  • 进行Qos的时候，将流标号设置为一个随机数，然后利用一种可以设置流的协议RSVP在路由器上进行QoS设置。当包发送的时候需要QoS的时候，就带上RSVP预想的流标号，这样就能使用这个RSVP设置的Qos，路由器接收到了IP包后先将查找流标号关键字，然后做出相应的处理。
  • 只有流标号、源地址、目标地址三项完全一致时，才被认为是一个流。

有效载荷长度（Payload Length）：

• 大小：16 Bit。但是为了发送更大的包，可以增加大型有效载荷选项，选项长度为32 Bit，可以发送最大4G字节的包。
• 功能：不包括首部长度，只表示数据部分的长度，如果有可选项的话，会加上可选项的长度。

下一个首部：

• 大小：8 Bit。
• 功能：相当于IPv4中的协议，没拓展首部的时候表示IP的上一层协议是TCP还是UDP；有拓展首部的话，表示该字段后面第一个拓展首部的协议类型。

跳数限制（Hop Limit）：

• 大小：8 Bit。
• 功能：与IPv4中的TTL相同，每经过一次路由器就-1。

源地址：

• 大小：128 Bit。
• 功能：表示发送端IP地址。

目标地址：

• 大小：128 Bit。
• 功能：表示接收端IP地址。

IPv6扩展首部：

• 大小：没有限制。
• 功能：
  • 因为IPv6的首部长度固定，没法加入可选项，所以用扩展首部对功能进行有效扩展。
  • 介于IPv6首部与TCP/UDP首部中间，扩展首部还可以包含扩展首部协议和写一个扩展首部字段（后面一直追加扩展）。
  • IPv6中没有标识以及标志字段，所以用扩展首部来对数据进行分片。
  • 切片的时候，可以设置扩展域（Fragement Header）为44。（44 Bit？还是字节？）
    

分片处理变成了可选项来做。

---

UDP

UDP数据报格式：

源端口号：

• 大小：16 Bit。
• 功能：表示发送端端口号，是可选项，没有源端口号的时候该字段的值设置为0，可用于不需要返回的通信中。

目标端口号：

• 大小：16 Bit。
• 功能：表示接收端端口。

包长度：

• 大小：8 Bit。
• 功能：保存了UDP首部和数据的长度和。

校验和（没搞懂）：

• 大小： ？。
• 功能：
  • 为提供可靠的UDP首部和数据而设计。
  • 附加在UDP伪首部和UDP数据报之前，通过在最后一位增加一个0将全长增加16倍。（为什么是16倍？而且这个0加在哪？）。
  • 将UDP首部的校验和字段设置为”0“。
  • 以16 Bit为单位进行1的补码和，并将所得到的1的补码写入校验和字段。
  • 不使用就全填0，此时速度会变快，但是如果遇到损坏，可能对其他通信造成不好的影响，所以比较推荐使用。
• 值：校验和字段的值是校验和字段以外剩下部分的1的补码和，所以，包括校验和字段在内的所有数据之和结果为”16位全部为1“是，才会被认为所受到的数据是正确的。

伪首部：

• 来源：接收主机在收到UDP数据报以后，从IP首部获知IP地址信息构造UDP伪首部，在进行校验和计算。
• 大小：IPv4的情况下源IP地址大小为32 Bit，IPv6的情况下是128 Bit。填充一般是0。
• 使用理由：
  • TCP/IP识别通信应用有5大要素，分别为”源IP地址“，”目标IP地址“，”源端口“，”目标端口“，”协议号“。
  • UDP只包含两个，剩下的在IP首部里面，不检验完全可能会出现不该收到包的应用收到了包，该收到包的应用没收到包。
  • IPv6的IP首部没有校验和字段，TCP/UDP通过伪首部，可以在即使IP首部不可靠的情况下也能提供可靠的通信传输。

---

TCP

源端口号：

• 大小：16 Bit。
• 功能：表示发送端端口号。

目标端口号：

• 大小：16 Bit。
• 功能：表示接收端端口号。

***：

• 大小： 32 Bit。
• 功能：
  • 指发送数据的位置，每发送一次，就累加一次该数据字节数的大小。（就是返回指定位置的，上面的讲传输的时候用到的，0-1000，1001-2000那个）。
  • 初始***是建立连接时随机生成的，通过SYN传递给接收端主机。
  • SYN和FIN包并不携带数据，但是会作为一个字节增加对应的***。

确认应答号：

• 大小：32 Bit。
• 功能：指下次应该收到的数据的***，发送端收到这个后可以认为这之前的数据已经被正常接收。

数据偏移：

• 大小：4 Bit。
• 功能：感觉就是首部长度，跟IP的一样，单位为4字节，如果首部长为20字节，那么这个字段就可以设置为5。

保留：

• 大小：4 Bit。
• 功能：为了以后拓展使用，一般设为0，但是不为0，包也不丢弃。所以应该是，为0表不丢弃，不为0表丢弃，但功能还没启用？

控制位：

• 大小：8 Bit。

窗口大小：

• 大小：16 Bit。
• 功能：用于通知从相同TCP首部的确认应答号所指的位置开始，能接收的数据的大小（8字节），TCP不能发送超过这个大小的数据。但如果窗口大小为0，可以发送指针探测，了解最新的窗口大小，但这个数据必须是1字节。（就是探针返回来的只能是1字节表示的？窗口不是还跟段有关吗？）

伪首部：

校验和：

• 和UDP差不多，区别在于TCP的校验和无法关闭，必须开启。
• 使用校验和的目的：
  • TCP和UDP的校验和是一种检查，检查是否由路由器内存故障或程序漏洞导致了数据被破坏。
  • 在互联网中发送数据包要经过好多个路由器，一旦其中一个发生了故障，经过该路由器的包、协议首部或数据就极有可能被破坏。

紧急指针：

• 大小：16 Bit。
• 功能：
  • 只有在URG控制位为1时有效。
  • 表示紧急数据的指针，即从数据部分的首位，到紧急指针指向的位置，这之间是紧急数据。
  • 一般在暂时中断通信，或中断通信的情况下使用，此外也用作表示数据流分段的标志。

选项：

• 大小：长度可变，最大为40字节，尽量调整为32的整数倍。
• 功能：用于提高TCP的传输性能。
• 部分说明：
  • 类型2：MSS，连接时决定最大段长度情况。
  • 类型3：窗口扩大，是一个用来改善TCP吞吐量的情况，窗口字段只有16位，所以最大发送64K字节数据（为啥是64K，没搞错吧，不是65535吗），使用这个选项可以扩大到1G。
  • 类型8：时间戳字段，如果内容很大，32位***可能用完，但是由于传输不稳定，可能较晚的时间点收到较早的***，产生混淆，所以加入时间戳，可以区分新老序号。
  • 类型4、5：用于选择确认应答，有了这个可以最大四次数据丢失的确认应答，因此在避免无用重发的同时，还能提高重发的速度，从而也能提高网络的吞吐量。

窗口大小和吞吐量：设最大吞吐量为 T m a x T_{max} Tmax​，窗口大小为 W W W，往返时间为 R T T RTT RTT，则 T m a x = W R T T T_{max} = \frac{W}{RTT} Tmax​=RTTW​。

---

从浏览器中输入url之后发生了什么

参考内容：

• 《计算机网络第七版》谢希仁，章节6.1
• Segmentfault

1. DNS解析：浏览器查询 DNS，获取域名对应的IP地址:具体过程包括浏览器搜索自身的DNS缓存、搜索操作系统的DNS缓存、读取本地的Host文件和向本地DNS服务器进行查询等。对于向本地DNS服务器进行查询，如果要查询的域名包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析(此解析具有权威性)；如果要查询的域名不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析（此解析不具有权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将根据其设置发起递归查询或者迭代查询；
2. TCP连接：浏览器获得域名对应的IP地址以后，浏览器向服务器请求建立链接，发起三次握手；
3. 发送HTTP请求：TCP/IP链接建立起来后，浏览器向服务器发送HTTP请求；
4. 服务器接收请求并返回HTTP报文：服务器接收到这个请求，并根据路径参数映射到特定的请求处理器进行处理，并将处理结果及相应的视图返回给浏览器；
5. 浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对js文件、css文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；
6. 展现页面/连接结束：浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

---

DNS服务器基本流程

参考内容：

• 《计算机网络第七版》谢希仁，章节6.1
• 博客文章
• 知乎文章

在运输层协议之上，还需要有应用层协议。

应用层的作用就是协调不同主机中的多个应用进程之间的通信和协同工作。

域名系统概述

域名系统DNS（Domain Name System）：是互联网使用的命名系统，便于把人们使用的机器名字转换为IP地址，计算机用户是间接使用DNS。

IP地址：

• IP地址是一个32位的二进制数，通常被分割为4个“8位二进制数”（也就是4个字节）。IP地址通常用“点分十进制”表示成（a.b.c.d）的形式，其中，a,b,c,d都是0~255之间的十进制整数。例：点分十进IP地址（100.4.5.6），实际上是32位二进制数（01100100.00000100.00000101.00000110）。
• IPv4是32位，IPv6是128位。

DNS作用：主机地址是32位的二进制，IP地址是点分十进制，都不好记，主机名字比较好记，DNS能把主机名字转换为IP地址。

DNS返回的映射信息：

• TTL：服务器在缓存中保存该资源记录的时长。
• class：网络/协议类型，IN就是internet，现在DNS系统主要支持的就是IN。
• type：资源记录类型，A是IPv4，AAAA是IPv6。
  

解析：DNS被设计成一个联机分布式数据库系统，并采用客户端服务器方式，DNS使大多数名字都在本地进行解析（解析就是转换的意思，地址解析可能包含多次的查询请求和回答过程），仅少数解析需要在互联网上通信，因此DNS系统效率很高。

域名服务器：域名到IP地址的解析是由分布在互联网上的许多域名服务器程序共同完成的，域名服务器程序在专设的结点上运行，人们把运行域名服务器程序的机器叫做域名服务器。（就是把原本的本地一些host对应信息转换到了一个个的服务器去做？这样本地占用空间就少了，这样的话树型结构很合理）。

域名到IP地址解析过程：

1. 当某应用进程需要解析的时候（查host不存在的话），就调用解析程序，这时这个程序会成为DNS的一个客户，把待解析的域名放到DNS请求报文中，以UDP用户数据报方式发送给本地域名服务器（用UDP是为了减少开销）。
2. 本地域名服务器找到域名后，把对应的IP地址放在回答报文中返回，应用程序就能获得主机IP地址了。
3. 如果找不到的，就把本地域名服务器作为一个客户，向另一个域名服务器发出查询请求，这个过程可以一直重复直到找到位置。（本地域名服务器能做客户，再往上客户就不变了，具体可以看下面的查询方式。）

---

互联网的域名结构

域名：

• 采用层次树状结构的命名方法。
• 每一个域名都是有标号序列组成，各标号之间用点（.）隔开。

DNS域名规定：

• 域名中的标号都由英文字母和数字组成，每一个标号不超过63个字符，也不区分大小写。
• 标号中除了连字符-不能用其他标点符号。
• 最低级域名在左边，*在右边。
• 由多个标号组成完整域名总计不超过255个字符。
• 各级域名由上一级的域名管理机构管理，而最高的*域名则由ICANN进行管理。

注意：域名中的.和IP地址中的.没有一一对应关系，IP地址一定有三个点，但每个域名的点不一定是三个。

*域名分三大类：

1. 国加*域名 nTLD：cn表示中国，us表示美国，uk表示英国，等。
2. 通用*域名 gTLD：com公司企业，net网络服务机构，edu美国专用的教育机构，等。
3. 基础结构域名：只有一个，arpa，用于反向域名解析，因此又称为反向域名。

互联网的域名空间：

---

域名服务器

区：

• 设计原因：理论上，让每一级的域名都有对应服务器，像上面的树形结构一样，但是这样服务器就太多了，使域名系统运行效率降低，所以采用划分区的方法。
• 概念：一个服务器（机器）所负责管辖的范围叫做区。
• 设计：
  • 各单位根据具体情况来划分自己管辖范围的区，但在一个区中所有的节点必须是能够连通的。
  • 每一个区设置相应的权限域名服务器（authoritative name server），用来保存该区中所有主机域名到IP地址的映射。
  • DNS服务器的管辖范围以区为单位，而不是以域为单位，区小于等于域，不可能大于域。

实例：
下面有左右两种区的划分，左边的区和域大小相同了；右边将一个域分成了两块，这两块都隶属于域abc.com，且各自都有相应的权限域名服务器，即abc.com和y.abc.com。
由此可知为什么区一定小于等于域，不过这个标准是在同级里面吧，不能用三级域名和二级的区来比较，区是从整个域分出来的，是域的子集。

---

域名服务器四种类型

DNS域名服务器树状结构图：

对应上图的b，可以看出DNS域名服务器也是按照层次安排的，每一个域名服务器都只对域名体系中的一部分进行管辖，根据所起作用可以分为四种类型。

1. 根域名服务器（root name server）：

• 功能：所有的根域名服务器知道所有*域名服务器的域名和IP地址。（所有？应该是知道所有的*域名服务器位于13个分组中的哪一个）
• 内容：只有13个不同IP地址的域名。（这13个应该不是按照*域名分类分出来的，就是统计学分出来的吧，a-m13个字母，将所有的*域名服务器分成13组。）
• 起作用方式：本地服务器无法解析，就要首先求助于根域名服务器，但是并不是直接把查询域名转换成IP地址返回（毕竟就13个），而是告诉本地服务器下一步应当找到哪一个*域名服务器进行查询。（这样才合理，就像图书管理员，告诉你去第几层去找，剩下的就是你自己的事了。）
• 技术：采用任播技术，任播的IP数据报的终点是一组在不同地点的主机，但是有相同的IP地址，IP数据报交付离源点最近的一台主机。

2. *域名服务器（TLD）：

• 功能：负责在该*域名服务器注册的所有二级域名。收到DNS查询请求后，就给出相应的回答，可能直接出结果，也可能是继续查找的去权限域名服务器IP地址。

3. 权限域名服务器：

• 功能：负责管理一个区的域名服务器，每个区都各设有一个权限域名服务器，查到了就返回，查不到就告诉发出查询请求的DNS客户，下一步找哪一个权限域名服务器。
• 注意：这已经是最下层了，不能再往下跳了，接下来的查找都是在权限域名服务器里面跳。

4. 本地域名服务器：

• 定位：并不属于域名服务器层次结构。
• 提供者：每一个互联网提供者ISP都可以拥有一个本地域名服务器，又是也叫默认域名服务器。
• 功能：
  • 当一台主机发出DNS查询请求时，这个查询请求报文就会发送给本地域名服务器。（hosts文件查不到才这样吧，然后本地域名服务器变成一个客户。）
  • 本地域名服务器离用户较近，一般不超过几个路由器的距离，当要查询的主机名也属于同一本地ISP时，该本地域名服务器就能立即将所查询的主机名转换为IP地址，而不需要去询问其他的域名服务器。

---

数据复制/递归查询/迭代查询

数据复制：

• 目的：为了提高域服务器的可靠性。
• 方法：
  • DNS域名服务器把数据复制到几个域名服务器来保存，其中一个是主域名服务器（master name server），其他的是辅助域名服务器（secondary name server），当主域名服务器出现故障时，辅助域名服务器可以保证DNS的查询工作不会中断。
  • 主域名服务器定期把数据复制到辅助域名服务器中，而更改数据只能在主域名服务器中进行，这样就保证了数据的一致性。

递归查询（recursive query）：

• 使用位置：主机 向 本地域名服务器查询一般用这个。
• 方法：如果主机要查的域名的IP地址本地域名服务器不知道，那么本地域名服务器就以DNS客户的身份，代替主机向其他根域名服务器继续发出查询请求报文，而不是让主机自己查询。
• 返回结果：要么是IP地址，要么是报错，表示找不到。

迭代查询（iterative query）：

• 使用位置：本地域名服务器 向 根域名服务器查询通常用这个。
• 方法：根域名服务器收到请求后，要么返回要查询的IP地址，要么告诉本地域名服务器下一步去哪查，让本地域名服务器继续后面的查询。

两种查询区别：
上面说的使用位置都是通常，并不绝对，取决于最初的查询请求报文设置的是要求哪一种查询方式。

高速缓存：

• 位置：本地域名服务器中。
• 目的：为了提高DNS查询效率、减轻根域名服务器的负载、减少互联网上的DNS查询报文数量。
• 原理：
  • 如果近期已经查询过了，那么高速缓存中就会有对应的IP地址，本地域名服务器就不必向根域名服务器重新查询，直接从高速缓存中取出。
  • 如果本地域名服务器的缓存中没有对应的IP地址，如果查询的为y.abc.com，而缓存中有dns.com的IP地址，那么本地域名服务器也不用向根域名服务器查询，可以直接向com*域名服务器发送查询请求报文，可以很好的达到目的。
• 过期时间：虽然名字与IP地址之间的绑定不常变，但是为了保持高速缓存中内容的正确性，还是要定期删除，删除之后下次就得重新授权获取信息了，过期时间来自权限域名服务器的回答响应，其中绑定了存在时间，毕竟人家才知道换不换，啥时候换。
• 主机维护：主机里面也有缓存，许多主机启动的时候会从本地域名服务器下载名字和地址的全部数据库，只有在这里找不到名字的时候才使用域名服务器，主机会对本地域名服务器的数据库进行维护，定期检查域名服务器来获取新的映射信息，同时主机也要删掉无效的项（删自己的还是本地域名服务器的？都删？）

流程总结：

1. 在浏览器中输入www.qq.com域名，操作系统会先检查自己本地的hosts文件是否有这个网址映射关系，如果有，就先调用这个IP地址映射，完成域名解析。
2. 如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3. 如果hosts与本地DNS解析器缓存都没有相应的网址映射关系，首先会找TCP/IP参数中设置的首选DNS服务器，在此我们叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4. 如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性。
5. 如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式（即迭代），本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该*域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找qq.com域服务器，重复上面的动作，进行查询，直至找到www.qq.com主机。
6. 如果用的是转发模式（即递归），此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。