计算机网络--从五层模型开始(完善中)

---

---

OSI 7、五层模型、TCP/IP 4

计网主要有3个模型：OSI7层模型、五层模型和TCP/IP 4层模型。
我们主要从5层模型来学习：

1. 应用层：通过进程之间的交互完成特定的应用；
2. 传输层：为进程之间通信提供数据传输服务；
3. 网络层：IP选址和路由选择；
4. 链路层：物理地址和链路管理；
5. 物理层：实现bit流之间的透明传输，屏蔽具体传输介质的物理设备的差异。

应用层：可分为 应用层、表示层、会话层，这样就变成了 OSI 七层模型；链路层和物理层可以合并为网络接口层，这样转化为了 TCP/IP 四层模型。

图片来源

1. 应用层

1.1 DNS

DNS （Domain Name System 的缩写）的作用很简单，就是根据域名查出IP地址，所以它是一个巨大的映射系统（你可以把它想象成一本巨大的电话本）。

域名有什么优势？
：域名比IP好记，你想www.baidu.com好记还是 14.215.177.39好记。

并且，一个域名可能对应多个IP，如下所示：

1.1.1 DNS解析过程

域名转换为IP的大致流程：

图中 部分组成图片 来源于超详细 DNS 协议解析 - 小牛肉的文章 - 知乎

1. 浏览器输入地址，首先在浏览器的域名缓存中找！没找到则进行下一步；
2. 然后浏览器这个进程去调操作系统某个库里的gethostbyname函数(例如，Linux GNU glibc标准库的gethostbyname函数)，没找到则进行下一步；
3. 然后呢这个函数通过网卡给DNS服务器发UDP请求，接收结果，然后将结果给返回给浏览器。

Windows10 下的 hosts 文件存放在 C:\Windows\System32\drivers\etc\hosts

面试官:讲讲DNS的原理？
超详细 DNS 协议解析 - 小牛肉的文章 - 知乎

---

---

1.2 HTTP协议

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。

1. 客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。
2. 服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP工作原理

1.2.1 URI & URL

• URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。
• URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，⽽且还指明了如何 locate 这个资源。
• URN(Uniform Resource Name) 是统一资源名称 定义某事物的身份。

网上很多解释：URI的作⽤像身份证号⼀样，URL的作⽤更像家庭住址⼀样，URN如同一个人的名字。URL是⼀种具体的URI，它不仅唯⼀标识资源，⽽且还提供了定位该资源的信息。

我比较赞同URL和URN的解释，但我觉得URI更像是一个概念，只要可以唯一标识一个资源，那么就可以将其称为URI。

三者之间的关系可以使用下图表示：

URL一般格式

http://www.Alvin.com:8080/index/article?id=alvin#fragment

• 协议：指定传输协议，如： http、https、ftp等
• 登录信息：可选，指指用户名和密码作为从服务器端获取资源时必要的登录信息（身份认证）。
• 服务器地址：可以是域名www.jianshu.com，也可以是ip:192.168.1.10
• 端口：可选，指定服务器连接的网络端口。，若省略则使用该协议的默认端口。
• 文件路径：指定服务器上的路径来定位指定的资源。
• 参数：可选，用于给动态网页（如使用CGI、ISAPI、PHP/JSP/ASP/ASP.NET等技术制作的网页）传递参数，可有多个参数，用“&”符号隔开，每个参数的名和值用“=”符号隔开。
• 片段：可选，片段用于指定网络资源中的片断。html页面中片段则是描点。例如一个网页中有多个名词解释，可使用片段可直接定位到某一名词解释（描点的位置）。

1.2.2 HTTP请求方法

图片来源

八种请求方法：

名称	特点
GET	向指定的资源发出“显示”请求
POST	向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）。数据被包含在请求本文中。这个请求可能会创建新的资源或修改现有资源，或二者皆有。
HEAD	与GET方法一样，都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分。它的好处在于，使用这个方法可以在不必传输全部内容的情况下，就可以获取其中“关于该资源的信息”（元信息或称元数据）。
PUT	向指定资源位置上传其最新内容。
DELETE	请求服务器删除Request-URI所标识的资源。
TRACE	回显服务器收到的请求，主要用于测试或诊断。
OPTIONS	这个方法可使服务器传回该资源所支持的所有HTTP请求方法。
CONNECT	HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）。

主要使用GET和POST方法，所以只是对这两者进行对比：

1. GET提交的数据会放在URL之后，也就是请求行里面，以?分割URL和传输数据，参数之间以&相连，如EditBook?name=test1&id=123456。POST方法是把提交的数据放在HTTP包的请求体中。
2. GET提交的数据大小有限制(因为浏览器对URL的长度有限制)，而POST方法提交的数据没有限制。

1.2.3 HTTP响应状态

浏览器在进行资源请求之后，服务器会给于响应。响应主要由3部分构成：状态码，响应报头，响应报文。如下所示：

图片来源

所有HTTP响应的第一行都是状态行，依次是当前HTTP版本号，3位数字组成的状态代码，以及描述状态的短语，彼此由空格分隔。

状态码：状态码是由3位数组成，第一个数字定义了响应的类别，且有五种可能取值。

• 1XX：表示通知信息，请求收到了或正在处理
• 2XX：表示成功
  - 200 OK：表示从客户端发送给服务器的请求被正常处理并返回；
  - 204 No Content：表示客户端发送给服务器的请求得到了成功处理，但在返回的响应报文中不含实体的主体部分（没有资源可以返回）；
  - 206 Patial Content：表示客户端进行了范围请求，并且服务器成功执行了这部分的GET请求，响应报文中包含由Content-Range指定范围的实体内容。
• 3XX：表示重定向，如要完成请求还必须采取进一步行动
  - 301 Moved Permanently：永久性重定向，表示请求的资源被分配了新的URL，之后应使用更改的URL；
  - 302 Found：临时性重定向，表示请求的资源被分配了新的URL，希望本次访问使用新的URL；
  - 303 See Other：表示请求的资源被分配了新的URL，应使用GET方法定向获取请求的资源；
  - 304 Not Modified（协商缓存命中后的返回代码）：表示客户端发送附带条件（是指采用GET方法的请求报文中包含if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since中任一首部）的请求时，服务器端允许访问资源，但是请求未满足条件的情况下返回改状态码；
  - 307 Temporary Redirect：临时重定向，与303有着相同的含义，307会遵照浏览器标准不会从POST变成GET；（不同浏览器可能会出现不同的情况）
• 4XX：表示客户端差错，如请求中错误的语法。
  - 400 Bad Request：表示请求报文中存在语法错误
  - 401 Unauthorized：未经许可，需要通过HTTP认证；
  - 403 Forbidden：服务器拒绝该次访问（访问权限出现问题）
  - 404 Not Found：表示服务器上无法找到请求的资源，除此之外，也可以在服务器拒绝请求但不想给拒绝原因时使用；
• 5XX：服务端内部错误
  - 500 Inter Server Error：表示服务器在执行请求时发生了错误，也有可能是web应用存在的bug或某些临时的错误时；
  - 503 Server Unavailable：表示服务器暂时处于超负载或正在进行停机维护，无法处理请求；

响应报头
常见的响应报头字段有: Server, Connection…。
响应报文
服务器返回给浏览器的文本信息，通常HTML, CSS, JS, 图片等文件就放在这一部分。

访问我自己的博客的时候：

1.2.4 长、短连接

HTTP1.0中默认短连接。

其意味着 Client和Server每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。

短连接有一些缺点：

网页中一般都包含HTTP、CSS、JavaScript和图片等资源，短连接获取一个资源就重新进行连接，这样很消耗资源。

所以从HTTP 1.1开始默认使用长连接（PersistentConnection）和请求的流水线（Pipelining）处理:

在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。

开启长连接未在响应头中添加 Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点。 keep-alive具有一个保持时间，并不会永久保持连接。

1.2.5 session & Cookie

1.2.5.1 Cookie

Cookie，有时也用其复数形式 Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。百度百科

因为 HTTP 协议是无状态的，即服务器不知道用户上一次做了什么，这严重阻碍了交互式 Web 应用程序的实现。

例如：当你浏览某个网站的时候，由web服务器创建一个小的文本文件在你的硬盘上，用于记录你的用户名、密码、浏览的网页、停留的时间等等信息。当你再次来到这个网站时，web服务器会先看看有没有它上次留下来的cookie。如果有的话，会读取cookie中的内容，来判断使用者，并送出相应的网页内容（比如在页面显示欢迎你的标语，或者让你不用输入ID、密码就直接登录等等）。

当客户端要发送HTTP请求时，浏览器会先检查下是否有对应的cookie。有的话，则自动地添加在request header中的cookie字段。注意，每次HTTP请求时，如果有cookie，浏览器都会自动带上cookie发送给服务端。
=--------------------------------------------------------------------------------------------------------------------------------------=
那么把什么数据放到cookie中就很重要了，因为很多数据并不是每次请求都需要发给服务端，毕竟会增加网络开销，浪费带宽。所以对于那设置“每次请求都要携带的信息（最典型的就是身份认证信息）”就特别适合放在cookie中，其他类型的数据就不适合了。

Cookie格式

Cookie中保存的信息都是文本信息，在客户端和服务器端交互过程中，cookie信息被附加在HTTP消息头中传递，cookie的信息由键/值对组成。下面是一个HTTP头中cookie的例子：

// HTTP 1.0
"key = value; expires= Sat, 19 Apr 2021 02:26:00 GMT; domain= csdn.net; path=/; secure; HttpOnly"

// HTTP 1.1
"key = value; MaxAge= 5000; domain= csdn.net; path=/; secure; HttpOnly"

• Expires：选项用来设置“cookie 什么时间内有效”。Expires其实是cookie失效日期，Expires必须是 GMT 格式的时间（可以通过 new Date().toGMTString()或者 new Date().toUTCString() 来获得）。如expires=Sat, 08 Sep 2018 02:26:00 GMT表示cookie将在2018年9月8日2:26分之后失效。对于失效的cookie浏览器会清空。如果没有设置该选项，这样的cookie称为会话cookie。它存在内存中，当会话结束，也就是浏览器关闭时，cookie消失。
• MaxAge：http/1.1协议中Expires已经由 Max age 选项代替，两者的作用都是限制cookie 的有效时间。Expires的值是一个时间点（cookie失效时刻= Expires），而Max age的值是一个以秒为单位时间段（cookie失效时刻= 创建时刻+ Max age）。 另外， Max age的默认值是 -1(即有效期为 session )； Max age有三种可能值：负数、0、正数。负数：有效期session；0：删除cookie；正数：有效期为创建时刻+ Max age
• Domain和Path：Domain 属性定义可访问该cookie的域名，对一些大的网站，如果希望cookie可以在子网站中共享，可以使用该属性。例如设置Domain为 .bigsite.com ,则sub1.bigsite.com和sub2.bigsite.com都可以访问已保存在客户端的cookie，这时还需要将Path设置为/。
  Path 属性定义网站上可以访问cookie的页面的路径，缺省状态下Path为产生cookie时的路径，此时cookie可以被该路径以及其子路径下的页面访问；可以将Path设置为/，使cookie可以被网站下所有页面访问。
• Secure：Secure 值定义cookie的安全性，当该值为true时必须是HTTPS状态下cookie才从客户端附加在HTTP消息中发送到服务端，在HTTP时cookie是不发送的；Secure为false时则可在HTTP状态下传递cookie，Secure缺省为false。

Cookie的特点：

• Cookie是有空间限制的，大多数浏览器支持最大为 4096 字节的Cookie;

• Cookie具有存在时间限制（有效期）;

• 创建cookie时如果不指定生存有效期，则cookie只在浏览器关闭前有效，cookie会在服务器端和客户端传输，但是不会保存在客户机的磁盘上，打开新的浏览器将不能获得原先创建的cookie信息。

• Cookie最终都是以文件形式存放在客户端计算机中，所以查看和修改Cookie都是很方便的，这就是为什么常说Cookie不能存放重要信息的原因;

• Cookie有域和路径这个概念。域就是domain的概念，因为浏览器是个注意安全的环境，所以不同的域之间是不能互相访问Cookie的(当然可以通过特殊设置的达到 cookie 跨域访问)。路径就是routing的概念，一个网页所创建的Cookie只能被与这个网页在同一目录或子目录下得所有网页访问，而不能被其他目录下得网页访问;

• 同个网站可以创建多个Cookie，而多个Cookie可以存放在同一个Cookie文件中;

• Cookie清除：①:通过浏览器工具清除 cookie (有第三方的工具，浏览器自身也有这种功能) ②通过设置 Cookie的有效期来清除Cookie；

• Cookie信息保存在本地时会保存到当前登录用户专门目录下，保存的cookie文件名中会包含创建cookie所在页面网站的域名，当浏览器再次连接该网站时，会从本机cookie存放目录下选出该网站的有效cookie，将保存在其中的信息附加在HTTP消息头中发送到服务器端，服务器端程序就可根据上次保存在cookie的信息为访问客户提供“记忆”或个性化服务。

Chrome浏览器中 缓存存放位置：C:\Users\HP\AppData\Local\Google\Chrome\User Data\Default\Cache

Cookie的创建：

1. Cookie可以在服务器端创建，然后cookie信息附加在HTTP消息头中传到客户端，如果cookie定义了有效期，则本保存在客户端本地磁盘。

2. Cookie除了可以在服务器端创建外，也可以在客户端的浏览器中用客户端脚本(如 javascript)创建。客户端创建的cookie的性质和服务器端创建的cookie一样，可以保存在本地，也可以被传送到服务器端被服务器程序读取。

HTTP相关知识

1.2.5.2 session

session 在计算机中，尤其是在网络应用中，称为“会话控制”。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。百度百科

将Client和Server之间的交互，抽象为“会话”，进而形成“会话状态”，逐渐形成seesion的概念。

当浏览器第一次访问服务器时，服务器创建一个session对象(该对象有一个唯一的id,一般称之为sessionId),服务器会将sessionId以cookie的方式发送给浏览器。当浏览器再次访问服务器时，会将sessionId发送过来，服务器依据sessionId就可以找到对应的session对象。

sessionID实际上是在客户端和服务端之间通过HTTP Request 和 HTTP Response传来传去。sessionID按照一定的算法生成，必须包含在 HTTP Request 里面，保证唯一性和随机性，以确保Session的安全。
如果没有设置 Session 的生成周期， sessionID存储在内存中，关闭浏览器后该ID自动注销；重新请求该页面，会重新注册一个sessionID。如果客户端没有禁用Cookie，Cookie在启动Session会话的时候扮演的是存储sessionID 和 Session 生存期的角色。

---

我个人认为比较重要的： 不要混淆 session 和 session 实现。session更像是一个抽象的概念，由于HTTP是无状态协议，所以开发者为了记录用户状态而提出的概念。

如今常说的 session 是借助Cookie和后端存储（内存、数据库、文件、Redis等）的一种 session实现。

Cookie 是针对于客户端的存储； 后端存储 是在服务器的存储。

---

Java中的Seesion：

Session发展与其领域背景
Java中的Session

1.2.5.3 Cookie和session区别与联系

让我们用几个例子来描述一下cookie和session机制之间的区别与联系。一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费 5 杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：

1. 该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。
2. 发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。
3. 发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。

由于HTTP协议是无状态的，而出于种种考虑也不希望使之成为有状态的，因此，后面两种方案就成为现实的选择。
具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。同时我们也看到，由于采用服务器端保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到客户端保存对应标识的目的。
例子来源

1. session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中；
2. Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是在客户端部分中实现session的一种工具。

1.2.6 HTTPS

1. 端口︰HTTP的URL由http://起始且默认使用端口88，而HTTPS的URL由https://起始且默认
   使用端口443。
2. 安全性和资源消耗：HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP安全性没有HTTPS高，但是 HTTPS比HTTP耗费更多服务器资源。

对称加密∶ 密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密
算法有DES、AES等;
非对称加密∶ 密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥)，加密解密使用不同密钥（(公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。

---

---

2. 传输层

2.1 TCP协议

传输控制协议 TCP ( Transmission Control Protocol)

提供面向连接的，可靠的数据传输服务。

2.1.1 三次握手

TCP报文头

seq：序列号（Sequence number）占32位，用来标识从计算机A发送到计算机B的数据包的序号，计算机发送数据时对此进行标记。
ack：确认号（Acknowledge Number）确认号占32位，客户端和服务器端都可以发送，Ack = seq + 1 表示 seq 对应的数据已经收到了。

SYN：同步序列编号（Synchronize Sequence Numbers），该标志仅在三次握手建立TCP连接时有效。
ACK：确认位（Acknowledgement） ，只有当ACK=1时，确认号 ack 才有效，当ACK=0时，确认号 ack 无效，这时会要求重传数据，以保证数据的完整性。
FIN：当TCP完成数据传输后，需要断开时，提出断开连接的一方将其置为 1。
URG：紧急指针（urgent pointer）有效。
PSH：接收方应该尽快将这个报文交给应用层。
RST：重置连接。

注意：ack和ACK不同

两张动图-彻底明白TCP的三次握手与四次挥手
我终于搞懂了TCP的三次握手和四次挥手（图片案例超详解）
三次握手，四次挥手
TCP / IP

2.1.2 四次挥手

2.1.3 可靠传输

2.1.3.1 ARQ

1. 停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复ack)。如果过了一段时间(超时时间后)，还是没有收到ack确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组;
2. 在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认;

2.1.3.2 流量控制（滑动窗口）

• TCP 利用滑动窗口实现流量控制。
• 流量控制是为了控制发送方发送速率，保证接收方来得及接收。
• 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。
• 将窗口字段设置为 0，则发送方不能发送数据。

2.1.3.3 拥塞控制

为了方便，我们假设主机A给主机B传输数据。
我们知道，两台主机在传输数据包的时候，如果发送方迟迟没有收到接收方反馈的ack，那么发送方就会认为它发送的数据包丢失了，进而会重新传输这个丢失的数据包。
然而实际情况有可能此时有太多主机正在使用信道资源，导致网络拥塞了，而A发送的数据包被堵在了半路，迟迟没有到达B。这个时候A误认为是发生了丢包情况，会重新传输这个数据包。结果就是不仅浪费了信道资源，还会使网络更加拥塞。因此，我们需要进行拥塞控制。

拥塞控制

2.2 UDP协议

用户数据协议 UDP ( User Datagram Protocol )

提供无连接的，尽最大努力的数据传输服务(不保证数据传输的可靠性)。

2.3 TCP & UDP 不同

特点	TCP	UDP
基于连接	是	否
可靠传输	是	否
传输形式	字节流	数据报文段
传输效率	慢	快
消耗资源	多	少
应用场景	通信可靠	通信速度快

---

3. url过程

1. URL解析
2. 域名映射为 IP（DNS解析过程）
3. 浏览器发送http请求（应用层->传输层->网络层------网络层>传输层->应用层）
4. 服务器处理请求并响应Servlet处理、SpringMVC处理过程）
5. 浏览器接受响应，进行渲染（DOM树、CSS）

3.1 URL解析

3.2 DNS解析

3.3 发送http请求

3.4 服务器处理请求

从Java来说：

SpringMVC执行流程及工作原理

3.5 页面渲染

在浏览器输入URL回车之后发生了什么? 1
在浏览器输入URL回车之后发生了什么? 2

整体结构

图片来源