计算机网路-即将作废

daiwei-dave

已于 2024-04-28 16:51:13 修改

阅读量214

点赞数

文章标签： java

于 2017-11-07 16:07:49 首次发布

本文链接：https://blog.csdn.net/sinat_34814635/article/details/78469000

版权

OSI七层

在这里插入图片描述

1.物理层：物理层的作用就是通过物理手段把电脑连接起来，它主要规定了网络的一些电气特性，作用是负责传送0和1的电信号。

2.数据链路层：物理层就是传输电路的0和1信号的，但是单纯的0和1没有意义，必须规定解读方式：多少个0和1算一组？每个信号有什么意义？
——这就是链路层的意义，它在物理层的上方，确定了0和1的分组方式。

以太网协议：“以太网”规定，一组电信号构成一个数据包，叫做“帧（Frame）”；每一帧分成两个个部分：标头（Head）和数据（Data）。
MAC地址：以太网规定，连入网络的所有设备，都必须具有“网卡”接口。数据包必须是从一块网卡，传送到另一块网卡，网卡的地址，就是数据包的发送地址和接受地址，也叫MAC地址。

注意：内网也就是局域网，只需经过物理层和数据链路层就可以完成网络通信，无需经过网络层等已上层。

3.网络层：网络层的出现，他的作用是引入一套新的地址，使我们能够区分哪些计算机属于同一个子网，这个套机制就叫做“网络地址”，也就是“IP地址”。

4.传输层:“传输层”的功能，就是建立“端口到端口”之间的通信。相比之下，“网络层”的功能是建立“主机到主机"的通信。

5.会话层:会话层建立、管理、终止会话。（在五层模型里面已经合并到了应用层）对应主机进程，指本地主机与远程主机正在进行的会话

6.表示层:数据的表示、安全、压缩。（在五层模型里面已经合并到了应用层）格式有，JPEG、ASCll、DECOIC、加密格式等

7.应用层:网络服务与最终用户的一个接口。协议有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP

@see 计算机网络漫谈：OSI七层模型与TCP/IP四层（参考）模型 https://www.jianshu.com/p/c793a279f698

TCP/IP四层

TCP/IP四层：TCP/IP参考模型分为四个层次：应用层、传输层、网络互连层和主机到网络层。

在这里插入图片描述

1、主机到网络层　　
实际上TCP/IP参考模型没有真正描述这一层的实现，只是要求能够提供给其上层-网络互连层一个访问接口，以便在其上传递IP分组。由于这一层次未被定义，所以其具体的实现方法将随着网络类型的不同而不同。

2、网络互连层　　
　　网络互连层是整个TCP/IP协议栈的核心。它的功能是把分组发往目标网络或主机。同时，为了尽快地发送分组，可能需要沿不同的路径同时进行分组传递。
因此，分组到达的顺序和发送的顺序可能不同，这就需要上层必须对分组进行排序。

3、传输层　　
　　在TCP/IP模型中，传输层的功能是使源端主机和目标端主机上的对等实体可以进行会话。在传输层定义了两种服务质量不同的协议。
即：传输控制协议TCP（transmission control protocol）和用户数据报协议UDP（user datagram protocol）。

4、应用层　　
　　TCP/IP模型将OSI参考模型中的会话层和表示层的功能合并到应用层实现。"应用层"的作用，就是规定应用程序的数据格式。

@see TCP/IP四层模型 http://www.cnblogs.com/BlueTzar/articles/811160.html

网路协议的意义

因特网无疑是人类有史以来最伟大的设计，它互联了全球数亿台计算机、通讯设备，即便位于地球两端的用户也可在顷刻间完成通讯。
可以说『协议』是支撑这么一个庞大而复杂的系统有条不紊运作的核心，而所谓『协议』就是通讯双方所必须遵守的规则，在这种规则下，不同的数据报可能被解析为不同的响应动作。
简而言之，『协议』就是指如果发送和接收方按照这个规则进行数据报文的发送，即可在基本的数据传输之上得到某些特殊的功能或服务，否则你的数据别人是不认识的。例如：遵循 TCP 协议的两端，可以在不可靠的网络传输中得到可靠的数据传输能力。

网路通信的过程

应用层的职责

『应用层』算是距离用户最近的一层了，主机上的一个个的进程就构成了『应用层』。比如你在你的浏览器地址栏输入了「www.baidu.com」，你的浏览器在应用层会做哪些事情呢？
首先浏览器会使用 DNS 协议返回域名「www.baidu.com」所对应的 IP 地址，关于 DNS 我们待会详细介绍。
接着，应用层决定创建一个『TCP 套接字』，然后将这个请求动作封装成一个 Http 数据报并推入套接字中。
套接字分为两种类型，『TCP 套接字』和『UDP 套接字』，应用层同时可能会有几十个数据报的发出，而运输层也会收到所有的响应报文，那么它该如何区分这些报文到底是谁的响应报文呢？
而套接字就是用于区分各个应用层应用的，往往由端口号和 IP 地址进行标识，运输层只要查看响应报文的源端口号和 IP 地址就能够知道该将报文推送给哪个套接字了。
当一个应用层数据报被推动进套接字之后，应用层的所有工作也算是全部完成了，关于后续报文的去向，它已经不用管了。

TCP 和UDP 的本质区别

『TCP 套接字』和『UDP 套接字』两者本质上的区别在于，前者保证数据报可靠地到达目的地，但是必然耗时，而后者不保证数据报一定能到达目的地，但是速度快，这也是应用层协议在选择运输层协议的时候需要考虑的一点。

DNS 原理
首先明确一点的是，DNS 是一个应用层协议，并且它选择的运输层协议是 UDP，所以你的域名解析过程一般会很快，但也会经常出现解析失败的情况，然而刷新一下又好了。

具体原理请参考：完整的一次 HTTP 请求响应过程（一）https://juejin.im/post/5b10be81518825139e0d8160

问题思考：

HTTP有哪些method

HTTP Method的历史：
HTTP 0.9 这个版本只有GET方法
HTTP 1.0 这个版本有GET HEAD POST这三个方法
HTTP 1.1 这个版本是当前版本，包含GET HEAD POST OPTIONS PUT DELETE TRACE CONNECT这8个方法

get:客户端向服务端发起请求，获得资源。请求获得URL处所在的资源。
post:向服务端提交新的请求字段。请求URL的资源后添加新的数据。
head:请求获取URL资源的响应报告，即获得URL资源的头部
patch：请求局部修改URL所在资源的数据项
put：请求修改URL所在资源的数据元素。
delete：请求删除url资源的数据

HTTPS和HTTP的区别

https协议需要到CA申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输；https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
http默认使用80端口，https默认使用443端口

幂等

一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“getUsername()和setTrue()”函数就是一个幂等函数.

传输层的职责

总述：运输层的任务就是从应用层的各个进程的套接字那取回来所有需要发送的数据，然后选择 TCP 或者 UDP 将数据封装并推给下面的网络层待发送。

tcp三次握手
在这里插入图片描述

第一步：
客户端向服务端发送一份特殊的 TCP 报文，该报文并不包含应用层的数据，是一份特殊的报文，它的 TCP 首部中 SYN 字段值为 1 （参见上述报文格式）。
除此之外，客户端还会随机生成一个初始序号，填在报文的「序号」字段，代表当前报文的序号是这个，并且我后续的分组会基于这个序号递增。
然后该报文将会经网络层、链路层、物理层发送到服务端。
第二步：
如果分组丢失了，那么客户端会经过某个时间间隔再次尝试发送。
而如果分组准确的到达服务端了，服务端拆开 TCP 首部会看到，这是一个特殊的 SYN 握手报文，于是为此次连接分配缓存等资源。
接着服务端开始构建响应报文，SYN 是一个用于同步需要的字段，响应报文中依然会被置为 1，并且服务端也将随机生成一个初始序号放置的响应报文的序号字段中。
最后，服务端还会为响应报文中的确认字段赋值，这个值就是客户端发过来的那个序号值加一。
整体上的意思就是说，「我同意你的连接请求，我的初始序号为 xxx，你的初始序号我收到了，我等着你的下一个分组到来」
第三步：
客户端收到服务端的响应报文，于是分配客户端 TCP 连接所必须的缓存等资源，于是连接已经建立。
实际上从第三步开始，客户端就可以携带应用层数据向服务端交换报文了，以后的每份报文中，SYN 都为 0，因为它只是用于同步初始序号的，这一点需要明确。

思考
1.TCP为什么是三次握手，为什么不是两次或者四次

如果两次，那么B无法确定B的信息A是否能收到，所以如果B先说话，可能后面的A都收不到，会出现问题。

如果四次，那么就造成了浪费，因为在三次结束之后，就已经可以保证A可以给B发信息，A可以收到B的信息； B可以给A发信息，B可以收到A的信息。

@see TCP为什么是三次握手，为什么不是两次或者四次 && TCP四次挥手 https://www.cnblogs.com/zhuzhenwei918/p/7465467.html

tcp四次挥手

在这里插入图片描述
整体流程：

因为一条 TCP 连接会消耗大量的主机资源，不仅仅服务端需要分配各种缓存资源，客户端也同样需要分配相应资源。因为 TCP 是『全双工通信』，服务端和客户端两方其实是一样的，谁是客户谁是服务器是相对的。
强调这一点是为了说明，一条 TCP 连接不是只有客户端才能断开，服务端也同样可以主动断开连接，这一点需要清楚。
我们这里假设客户端主动发起断开连接的请求为例：
第一步：
客户端构建一份特殊的 TCP 报文，该报文首部字段 FIN 被置为 1，然后发送该报文。
第二步：
服务端收到该特殊的 FIN 报文，于是响应客户端一个 ACK 报文，告诉客户端，请求关闭的报文已经收到，我正在处理。
第三步：
服务端发送一个 FIN 报文，告诉客户端，我将要关闭连接了。
第四步：
客户端返回一个 ACK 响应报文，告诉服务端，我收到你刚才发的报文了，我已经确认，你可以关闭连接了。
当服务端收到客户端发送的 ACK 响应报文时，将释放服务端用于该 TCP 连接的所有资源，与此同时，客户端也会定时等待一定时间后完全释放自己用于该连接的相关资源。

具体细节：

首先，客户端发送一个特殊分组，该分组的序号为 u。发送完成之后，客户端进入 FIN-WAIT-1 这个状态，这个状态下，该 TCP 连接的客户端不再能发送数据报，但是是可以接受数据报的，它等待着服务端的响应报文。
接着，服务端收到客户端发送的终止连接报文请求，服务端构建响应报文，告诉客户端「序号 u+1 以前的分组我都收到了」，并且进入 CLOSE-WAIT 状态，这个状态持续时间很短。
服务端会紧接着发送它的 FIN 数据报，通知客户端我服务端即将关闭连接，并随即进入 LAST_ACK 状态等待客户端响应报文。
一旦客户端收到这个 FIN 报文，将返回确认报文并进入 TIME-WAIT 状态，等待 2MSL 时间间隔后完全释放客户端 TCP 连接所占用资源。
与此同时，当服务端收到客户端最后的确认报文，就将直接断开服务端连接并释放相关资源。

常用状态
常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

TIME_WAIT

TIME_WAIT 是主动关闭链接时形成的，等待2MSL时间，约4分钟。主要是防止最后一个ACK丢失。

CLOSE_WAIT

CLOSE_WAIT是被动关闭连接是形成的。根据TCP状态机，服务器端收到客户端发送的FIN，则按照TCP实现发送ACK，因此进入CLOSE_WAIT状态。但如果服务器端不执行close()，就不能由CLOSE_WAIT迁移到LAST_ACK，则系统中会存在很多CLOSE_WAIT状态的连接。此时，可能是系统忙于处理读、写操作，而未将已收到FIN的连接，进行close。此时，recv/read已收到FIN的连接socket，会返回0。

至于为什么最后客户端需要等 2MSL 时间长度再完全释放 TCP 相关资源呢？
那是因为 2MSL 是一份报文存在于网络中最长的时间，超过该时间到达的报文都将被丢弃，而如果客户端最后的确认报文于网络中丢失的话，服务端必将发起超时请求，重新发送第三次挥手动作，此时等待中的客户端就可随即重新发送一份确认请求。
这是为什么客户端等待一个最长报文传输时间的原因。有人可能好奇为什么前面的各次请求都没有做超时等待而只最后一次数据发送做了超时等待？
其实原因很简单，相信你也能想到，就是 TCP 自带计时能力，超过一定时间没有收到某个报文的确认报文，会自动重新发送，而这里如果不做等待而直接关闭连接，那么我如何知道服务端到底收到没我的确认报文呢。
通过等待一个最长周期，如果这个周期内没有收到服务端的报文请求，那么我们的确认报文必然是到达了服务端了的，否则重复发送一次即可。

经典问题

1.当你在浏览器地址栏输入一个URL后回车，将会发生的事情？

整体流程：
域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

其他参考：

首先嘛，你得在浏览器里输入要网址:
浏览器查找域名的IP地址
浏览器给web服务器发送一个HTTP请求
facebook服务的永久重定向响应
浏览器跟踪重定向地址
服务器“处理”请求
服务器发回一个HTML响应
浏览器开始显示HTML
浏览器发送获取嵌入在HTML中的对象
浏览器发送异步（AJAX）请求

1）这里着重理解下为何服务要进行永久重定向响应

1.跟搜索引擎排名有关：如果一个页面有两个地址，就像http://www.igoro.com/ 和http://igoro.com/，搜索引擎会认为它们是两个网站，结果造成每一个的搜索链接都减少从而降低排名。而搜索引擎知道301永久重定向是什么意思，这样就会把访问带www的和不带www的地址归到同一个网站排名下。

2.不同的地址会造成缓存友好性变差。当一个页面有好几个名字时，它可能会在缓存里出现好几次。即浪费存储空间。

@see 当你在浏览器地址栏输入一个URL后回车，将会发生的事情？https://www.jianshu.com/p/c83efcdb97c2

2.http状态码

201-206都表示服务器成功处理了请求的状态代码，说明网页可以正常访问。

200 -请求已成功，请求所希望的响应头或数据体将随此响应返回。

300-307表示的意思是：要完成请求，您需要进一步进行操作。通常，这些状态代码是永远重定向的。

    300（多种选择）  服务器根据请求可执行多种操作。服务器可根据请求者 来选择一项操作，或提供操作列表供其选择。 

    301（永久移动）  请求的网页已被永久移动到新位置。服务器返回此响应时，会自动将请求者转到新位置。您应使用此代码通知搜索引擎蜘蛛网页或网站已被永久移动到新位置。 
    302（临时移动） 服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。会自动将请求者转到不同的位置。但由于搜索引擎会继续抓取原有位置并将其编入索引，因此您不应使用此代码来告诉搜索引擎页面或网站已被移动。 
    303（查看其他位置） 当请求者应对不同的位置进行单独的 GET 请求以检索响应时，服务器会返回此代码。对于除 HEAD 请求之外的所有请求，服务器会自动转到其他位置。 
    304（未修改） 自从上次请求后，请求的网页未被修改过。服务器返回此响应时，不会返回网页内容。

    如果网页自请求者上次请求后再也没有更改过，您应当将服务器配置为返回此响应。由于服务器可以告诉 搜索引擎自从上次抓取后网页没有更改过，因此可节省带宽和开销。 

    305（使用代理） 请求者只能使用代理访问请求的网页。如果服务器返回此响应，那么，服务器还会指明请求者应当使用的代理。 
    307（临时重定向）  服务器目前正从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。会自动将请求者转到不同的位置。但由于搜索引擎会继续抓取原有位置并将其编入索引，因此您不应使用此代码来告诉搜索引擎某个页面或网站已被移动。

4xx（请求错误）这些状态码表示请求可能出错，妨碍了服务器的处理。

400 - 错误的请求。服务器不理解请求的语法。
401 -（未授权）请求要求身份验证。对于登录后请求的网页，服务器可能返回此响应。
403 -对不起，您没有权限请求此连接！
404 - 未找到。 ·404.0 -（无） – 没有找到文件或目录
405 - 用来访问本页面的 HTTP 谓词不被允许（方法不被允许）如设置了get请求而却用了post

5xx（服务器错误）这些状态码表示服务器在处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。

500（服务器内部错误）服务器遇到错误，无法完成请求。

@see http statusCode(状态码) 200、300、400、500序列 https://www.douban.com/note/218418718/

3.HTTP1.0和HTTP1.1的区别

1、HTTP 1.1支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理

HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。

HTTP 1.1则支持持久连接Persistent Connection, 并且默认使用persistent  connection. 在同一个tcp的连接中可以传送多个HTTP请求和响应. 多个请求和响应可以重叠，多个请求和响应可以同时进行. 更加多的请求头和响应头(比如HTTP1.0没有host的字段).

在1.0时的会话方式：
 1. 建立连接
 2. 发出请求信息
 3. 回送响应信息
 4. 关掉连接

 HTTP 1.1的持续连接，也需要增加新的请求头来帮助实现，例如，Connection请求头的值为Keep-Alive时，客户端通知服务器返回本次请求结果后保持连接；Connection请求头的值为close时，客户端通知服务器返回本次请求结果后关闭连接。HTTP 1.1还提供了与身份认证、状态管理和Cache缓存等机制相关的请求头和响应头。

请求的流水线（Pipelining）处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。例如：一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接。  HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容。

2.HTTP 1.1增加host字段

在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。

 HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）。此外，服务器应该接受以绝对路径标记的资源请求。

3、100(Continue) Status(节约带宽)

HTTP/1.1加入了一个新的状态码100（Continue）。客户端事先发送一个只带头域的请求，如果服务器因为权限拒绝了请求，就回送响应码401（Unauthorized）；如果服务器接收此请求就回送响应码100，客户端就可以继续发送带实体的完整请求了。100 (Continue) 状态代码的使用，允许客户端在发request消息body之前先用request header试探一下server，看server要不要接收request body，再决定要不要发request body。

4、HTTP/1.1中引入了Chunked transfer-coding来解决上面这个问题，发送方将消息分割成若干个任意大小的数据块，每个数据块在发送时都会附上块的长度，最后用一个零长度的块作为消息结束的标志。这种方法允许发送方只缓冲消息的一个片段，避免缓冲整个消息带来的过载。

5、HTTP/1.1在1.0的基础上加入了一些cache的新特性，当缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活（revalidation）。

HTTP协议与TCP/IP协议的关系

HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP属于应用层协议，在传输层使用TCP协议，在网络层使用IP协议。 IP协议主要解决网络路由和寻址问题，TCP协议主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP协议是可靠的、面向连接的。