网络协议详解

OSI 七层模型

OSI网络参考模型自下而上分层:

  1. 物理层

  2. 数据链路层

  3. 网络层

  4. 传输层

  5. 会话层

  6. 表示层

  7. 应用层

模型中常用的协议有: HTTP, HTTPS. FTP, SSH, STMP. TCP, UDP, DNS, ARP, RARP, ICMP等, 接下来一层一层看

数据是如何在层与层之间传递的?

比如现在要发送GET请求到http://www.abc.com

DNS解析

  1. 在客户端配置目标地址等相关信息后, 首先要通过DNS将域名解析出目标主机的IP地址, 客户端在本地缓存以及hosts文件中查找是否有缓存, 没有缓存则会发送请求到本地DNS服务器查询

    在通过浏览器缓存及host文件都无法解析域名的情况下,OS会将这个域名发送给计算机网络配置中DNS对应的地址(LDNS),即本地区的域名服务器。这个DNS通常都提供给你本地互联网接入的一个DNS解析服务,假如是在学校接入的互联网,那么这个本地区的域名服务器基本上是在学校中;如果是在小区接入的互联网,那么这个本地区的域名服务器就是提供给你接入互联网的应用服务上,也就是电信或联通
    

在这里插入图片描述

  1. 本地DNS服务器收到请求后, 有缓存就返回, 内有缓存就会询问根域名服务器, 请求IP地址, 根域名服务器是最高层次的, 不直接用于解析域名, 但可以指路
  2. 跟域名服务器收到请求后, 发现是.com, 就会返回.com顶级域名服务器, 让客户端去请求
  3. 本地DNS开始想顶级域名服务器请求, 顶级域名会返回www.abc.com 区域的权威DNS服务器, 让客户端去请求
  4. 本地DNS转向权威DNS, 权威DNS服务器查询后返回对应的IP地址
  5. 本地DNS将IP地址返回给客户端

发送请求
在这里插入图片描述

  1. 应用层封装http请求报文, 数据交给TCP处理

     TCP三次握手后建立连接,  从应用层到物理层, 每经过一层都会增加改层的首部, 数据到达目标主机后, 开始层层扒皮, 去掉相应层的首部, 最终得到数据.  
    
  2. TCP模块的处理

    TCP负责建立连接, 发送数据, 以及断开连接, TCP提供将应用层发来的数据顺利发送至目标端口的可靠传输

    为了实现TCP的这一功能, 需要在应用层数据的前端附加一个TCP首部, 首部中包含源端口和目标端口, 序号, 以及校验和, 随后附加了TCP首部的包再发给IP层

    为了传输方便,在传输层(TCP 协议)把从应用层处收到的数 据(HTTP 请求报文)进行分割,并在各个报文上打上标记序号及端 口号后转发给网络层

  3. IP模块的处理

    IP将TCP传过来的TCP首部和TCP数据合并起来当自己的数据, 并在TCP首部的前端加上自己的IP首部, 因此IP数据包中IP首部后面紧跟着TCP首部, 然后才是应用的数据首部和数据本身, IP首部包含接收端的IP地址和发送端的IP地址, 以及用来判断IP层上层使用的是什么种协议的信息(如上层是TCP或者UDP)

    IP包生成后, 参考路由控制表决定接受此IP包的路由或主机, 随后IP包将被发送给连接这些路由器或主机网络接口的驱动程序, 以实现真正的发送数据,

    ​ 如果不知道接收端的MAC地址, 可以利用ARP协议进行查找, 只要知道对端的MAC地址, 就可以将MAC地址和ip地址交给以太网驱动程序, 实现数据传输.

    在网络层(IP 协议),增加作为通信目的地的 MAC 地址后转发给链 路层。这样一来,发往网络的通信请求就准备齐全了。

  4. 网络接口的处理

    ​ 从IP传过来的IP包, 对于以太网驱动来说不过是就是数据, 给这数据加上以太网首部并进行发送处理, 以太网首部中包含接收端,发送端的MAC地址, 以及标志以太网类型的以太网数据的协议, 根据上述信息产生的以太网数据包将通过物理层传输给接收端, 发送处理中的FCS(帧校验序列)由硬件计算, 添加到包的最后, 设置FCS目的是为了判断数据包是否由于噪声而被破坏.

接收端的服务器在链路层接收到数据,按序往上层发送,一直到应用 层。当传输到应用层,才能算真正接收到由客户端发送过来的 HTTP 请求。

数据接收的过程

  1. 主机收到以太网数据包后, 首先从以太网的包首部找到MAC地址, 判断是否是发给自己的, 不是的话就丢弃. 如果是给自己的, 就查找以太网首部中的类型域从而确定以太网协议传送过来的数据类型, 如果是IP包, 就将数据传给处理IP的子程序, 如过是其他协议比如ARP, 就交给ARP子程序处理, 总之, 如果以太网首部的类型域包含了一个无法识别的协议类型, 则丢弃数据包

  2. IP模块的处理

    IP模块收到IP包, 也会做类似的处理, 判断IP地址是否是当前主机, 如果是的话则从IP包中解析出上层协议, 比如是TCP, 则会将去掉IP首部之后的数据传给TCP进行处理. 对于有路由器的情况下, 接收端的地址往往不是自己的地址, 此时需要借助路由控制表, 在调查应该送达的主机或者路由器以后转发数据

  3. TCP模块的处理

    TCP模块会首先计算一下校验和, 判断数据是否被破坏, 然后检查是否按照序号接收数据, 最后检查端口, 确定具体的应用程序

    数据接收完毕后, 接收端则发送一个确认回执给发送端, 如果这个回执信息未能到达发送端, 那么发送端会认为接收端没收到数据而一直反复发送.

  4. 接收端的应用程序会直接接收发送端发送的数据, 通过解析获得原始数据.

应用层

应用层负责向网络应用程序提供访问网络服务的接口, 最常用的http(s)协议就属于应用层的协议.

报文

http报文: 用于 HTTP 协议交互的信息被称为 HTTP 报文

报文结构: 在这里插入图片描述

请求报文: 请求行, 请求首部字段, 通用首部字段, 实体首部字段 - CR+LF-> 报文主体

相应报文类似: 响应行, 响应首部字段, 通用首部字段, 实体首部字段 - CR+LF-> 报文主体

首部字段

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之 间以 HTTP 协议进行通信的过程中,无论是请求还是响应都会使用首 部字段,它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

HTTP 首部字段重复了会如何?

当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时 会怎么样?这种情况在规范内尚未明确,根据浏览器内部处理逻辑 的不同,结果可能并不一致。有些浏览器会优先处理第一次出现的 首部字段,而有些则会优先处理最后出现的首部字段。

HTTP 首部字段根据实际用途被分为以下 4 种类型。

1. 通用首部字段(General Header Fields):请求报文和响应报文两方都会使用的首部

2.请求首部字段(Request Header Fields): 从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。

响应首部字段(Response Header Fields): 从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加内容,也会要求客户端附加额外的内容信息。

实体首部字段(Entity Header Fields): 针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更新时间等与实体有关的信息。

请求首部字段:
  1. Accept 首部字段可通知服务器,用户代理能够处理的媒体类型及媒体 类型的相对优先级。可使用 type/subtype 这种形式,一次指定多种媒 体类型。
     文本文件
     text/html, text/plain, text/css ... application/xhtml+xml, application/xml ..
       
     图片文件
      image/jpeg, image/gif, image/png ...
       
     视频文件
     video/mpeg, video/quicktime ..
       
     应用程序使用的二进制文件
     application/octet-stream, application/zip ...
       
     eg: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0
  1. Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及 字符集的相对优先顺序。另外,可一次性指定多种字符集。与首部字 段 Accept 相同的是可用权重 q 值来表示相对优先级

    eg: Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
    
  2. Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及 内容编码的优先级顺序。可一次性指定多种内容编码。

    eg: Accept-Encoding: gzip, deflate   
    

gzip: 由文件压缩程序 gzip(GNU zip)生成的编码格式
compress: 由 UNIX 文件压缩程序 compress 生成的编码格式,采用 Lempel- Ziv-Welch 算法(LZW)。
deflate: 组合使用 zlib 格式(RFC1950)及由 deflate 压缩算法 (RFC1951)生成的编码格式。
identity: 不执行压缩或不会变化的默认编码格式


4. Accept-Language 用来告知服务器用户代理能够处理的自然 语言集(指中文或英文等),以及自然语言集的相对优先级。可一次 指定多种自然语言集

eg: Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3


5.  Authorization 是用来告知服务器,用户代理的认证信息(证 书值)。通常,想要通过服务器认证的用户代理会在接收到返回的 401 状态码响应后,把首部字段 Authorization 加入请求中

eg: Authorization: Basic dWVub3NlbjpwYXNzd29yZA==


6. 条件请求,形如 If-xxx 这种样式的请求首部字段,都可称为条件请求。服务器接 收到附带条件的请求后,只有判断指定条件为真时,才会执行请求

If-Range 属于附带条件之一。它告知服务器若指定的 If- Range 字段值(ETag 值或者时间)和请求资源的 ETag 值或时间相一 致时,则作为范围请求处理。反之,则返回全体资源

对于只需获取部分资源的范围请求,包含首部字段 Range 即可告知服 务器资源的指定范围
接收到附带 Range 首部字段请求的服务器,会在处理请求之后返回状 态码为 206 Partial Content 的响应。无法处理该范围请求时,则会返 回状态码 200 OK 的响应及全部资源
eg: Range: bytes=5001-10000
```

  1. 首部字段 User-Agent 会将创建请求的浏览器和用户代理名称等信息传 达给服务器。

由网络爬虫发起请求时,有可能会在字段内添加爬虫作者的电子邮件
地址。此外,如果请求经过代理,那么中间也很可能被添加上代理服
务器的名称。
eg: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/201001
```

  1. Connection: keep-alive

    使用此字段来保持连接, 不用分多次请求, 只需要建立一次连接可以请求多次

    持久连接的好处在于减少了 TCP 连接的重复建立和断开所造成的额 外开销,减轻了服务器端的负载。另外,减少开销的那部分时间,使 HTTP 请求和响应能够更早地结束,这样 Web 页面的显示速度也就相 应提高了。

    在 HTTP/1.1 中,所有的连接默认都是持久连接,但在 HTTP/1.0 内并 未标准化。虽然有一部分服务器通过非标准的手段实现了持久连接, 但服务器端不一定能够支持持久连接。毫无疑问,除了服务器端,客 户端也需要支持持久连接。

在这里插入图片描述

响应首部字段

在这里插入图片描述

  1. Accept-Ranges 是用来告知客户端服务器是否能处理范围请求,以指定获取服务器端某个部分的资源。

  2. Content-Encoding 会告知客户端服务器对实体的主体部分选 用的内容编码方式。内容编码是指在不丢失实体信息的前提下所进行 的压缩

  3. Content-Language 会告知客户端,实体主体使用的自然语言

  4. Content-Length 表明了实体主体部分的大小(单位是字 节)。对实体主体进行内容编码传输时,不能再使用 Content-Length 首部字段

首部字段 Content-Length 表明了实体主体部分的大小(单位是字 节)。对实体主体进行内容编码传输时,不能再使用 Content-Length 首部字段

  1. 返回响应时使用的首部字段 Content-Range,能告知客 户端作为响应返回的实体的哪个部分符合范围请求。字段值以字节为 单位,表示当前发送部分及整个实体大小。

  2. Content-Type 说明了实体主体内对象的媒体类型。和首部字 段 Accept 一样,字段值用 type/subtype 形式赋值。 参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值

  3. Cookie 使用 Cookie 的状态管理

    管理服务器与客户端之间状态的 Cookie,虽然没有被编入标准化
    HTTP/1.1 的 RFC2616 中,但在 Web 网站方面得到了广泛的应用
    保留无状态协议这个特征的同时又要解决类似的矛盾问题,于是引入 了 Cookie 技术。Cookie 技术通过在请求和响应报文中写入 Cookie 信 息来控制客户端的状态。
    
    Cookie 会根据从服务器端发送的响应报文内的一个叫做 Set-Cookie 的 首部字段信息,通知客户端保存 Cookie。当下次客户端再往该服务器 发送请求时,客户端会自动在请求报文中加入 Cookie 值后发送出 去。
    
    服务器端发现客户端发送过来的 Cookie 后,会去检查究竟是从哪一 个客户端发来的连接请求,然后对比服务器上的记录,最后得到之前 的状态信息。
    
实体首部字段

在这里插入图片描述

通用首部字段:

在这里插入图片描述

HTTP状态码

在这里插入图片描述

http的状态码是来描述这次请求的结果, 成功或失败原因等.

**204 成功但无实体内容

该状态码代表服务器接收的请求已成功处理,但在返回的响应报文中 不含实体的主体部分。另外,也不允许返回任何实体的主体。比如, 当从浏览器发出请求处理后,返回 204 响应,那么浏览器显示的页面 不发生更新。一般在只需要从客户端往服务器发送信息,而对客户端不需要发送新 信息内容的情况下使用。

206 返回部分内容

该状态码表示客户端进行了范围请求,而服务器成功执行了这部分的 GET 请求。响应报文中包含由 Content-Range 指定范围的实体内容。

301 永久重定向

永久性重定向。该状态码表示请求的资源已被分配了新的 URI,以后 应使用资源现在所指的 URI。也就是说,如果已经把资源对应的 URI 保存为书签了,这时应该按 Location 首部字段提示的 URI 重新保存。

302 临时重定向

和 301 Moved Permanently 状态码相似,但 302 状态码代表的资源不 是被永久移动,只是临时性质的。换句话说,已移动的资源对应的 URI 将来还有可能发生改变。比如,用户把 URI 保存成书签,但不会 像 301 状态码出现时那样去更新书签,而是仍旧保留返回 302 状态码 的页面对应的 URI。

303 See Other

该状态码表示由于请求对应的资源存在着另一个 URI,应使用 GET 方法定向获取请求的资源。
303 状态码和 302 Found 状态码有着相同的功能,但 303 状态码明确 表示客户端应当采用 GET 方法获取资源,这点与 302 状态码有区 别。使用 POST 方法访问 CGI 程序,其执行后的处理结果是希望 客户端能以 GET 方法重定向到另一个 URI 上去时,返回 303 状态 码。虽然 302 Found 状态码也可以实现相同的功能,但这里使用 303
状态码是最理想的。

304 Not Modified

该状态码表示客户端发送附带条件的请求时,服务器端允许请求访问资源,但未满足条件的情况。304 状态码返回时,不包含任何响应的主体部分。304 虽然被划分在 3XX 类别中,但是和重定向没有关系。

附带条件的请求是指采用 GET 方法的请求报文中包含 If-Match,If-Modified- Since,If-None-Match,If-Range,If-Unmodified-Since 中任一首部。

307 Temporary Redirect

同302 307 会遵照浏览器标准,不会从 POST 变成 GET。但是,对于处理响

应时的行为,每种浏览器有可能出现不同的情况

400 Bad Request

该状态码表示请求报文中存在语法错误。当错误发生时,需修改请求 的内容后再次发送请求。另外,浏览器会像 200 OK 一样对待该状态 码。

401 Unauthorized

该状态码表示发送的请求需要有通过 HTTP 认证(BASIC 认证、 DIGEST 认证)的认证信息。另外若之前已进行过 1 次请求,则表示 用 户认证失败。

返回含有 401 的响应必须包含一个适用于被请求资源的 WWW- Authenticate 首部用以质询(challenge)用户信息。当浏览器初次接收 到 401 响应,会弹出认证用的对话窗口。

403 Forbidden

该状态码表明对请求资源的访问被服务器拒绝了。服务器端没有必要 给出拒绝的详细理由,但如果想作说明的话,可以在实体的主体部分	对原因进行描述,这样就能让用户看到了。 未获得文件系统的访问授权,访问权限出现某些问题(从未授权的发

送源 IP 地址试图访问)等列举的情况都可能是发生 403 的原因。

404 Not Found

该状态码表明服务器上无法找到请求的资源。除此之外,也可以在服 务器端拒绝请求且不想说明理由时使用。

500 Internal Server Error

该状态码表明服务器端在执行请求时发生了错误。也有可能是 Web 应用存在的 bug 或某些临时的故障。

502

502状态码是服务器(不一定是[Web服务器](https://baike.baidu.com/item/Web服务器/8390210))作为[网关](https://baike.baidu.com/item/网关/98992)或[代理](https://baike.baidu.com/item/代理/3242667),以满足客户的要求来访问所请求的URL 。此服务器收到无效响应从上游服务器访问履行它的要求。

503 Service Unavailable

该状态码表明服务器暂时处于超负载或正在进行停机维护,现在无法 处理请求。如果事先得知解除以上状况需要的时间,最好写入 RetryAfter 首部字段再返回给客户端。

表示层

表示层有表示,演示的意思, 因此更关注数据的具体表现形式

表示层是进行"统一的网络数据格式"与某一台计算机或某一款软件特有的数据格式之间相互转换的分层, 表示层与表示层之间为了识别编码格式也会附加首部信息, 从而将实际传输的数据交给下一层处理,

会话层

会话层: 主要责任是决定采用何种连接方式,

eg: 发5封邮件, 1: 发一封建立一个连接, 随后断开, 2: 建立一个连接一次发5封, 3: 建立5个连接, 发5封邮件

会话层与应用层表示层一样, 在收到的数据前端附加首部信息再转给下一层.

传输层

传输层针对上层应用层, 提供处于网络连接状态中的两台计算机之间的数据传输.

TCP是传输层协议, 提供可可靠的字节流服务, 字节流服务是为了方便传输大数据, 将大块数据分割成以报文段为单位的数据包进行管理, 可靠的传输是指能够将数据准确可靠的传给对方, 且可以确认传送给对方.

TCP首部
在这里插入图片描述

UDP首部

在这里插入图片描述

为什么是三次握手?

在这里插入图片描述

这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足”在不可靠信道上可靠地传输信息”这一需求所导致的.

也是为了最小的代价验证会话双方的收发功能正常:

  • 第一次握手成功:说明客户端的数据可以被服务端收到,说明客户端的发功能可用,说明服务端的收功能可用。但客户端自己不知道数据是否被接收。
  • 第二次握手成功:说明服务端的数据可以被客户端收到,说明服务端的发功能可用,说明客户端的收功能可用。同时客户端知道自己的数据已经正确到达服务端,自己的发功能正常。但是服务端自己不知道数据是否被接收。
  • 第三次握手成功:说明服务端知道自己的数据已经正确到达客户端端,自己的发功能正常。至此服务成功建立。

在这里插入图片描述

  1. 第一次挥手:客户端 发送一个[FIN+ACK],表示自己没有数据要发送了,想断开连接,并进入FIN_WAIT_1状态(不能再发送数据到服务端,但能够发送控制信息ACK到服务端)。
  2. 第二次挥手:服务端收到FIN后,知道不会再有数据从客户端传来,发送ACK进行确认,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),服务端进入CLOSE_WAIT状态。
  3. 第三次挥手:服务端发送FIN给对方,表示自己没有数据要发送了,服务端进入LAST_ACK状态,然后直接断开TCP会话的连接,释放相应的资源。
  4. 第四次挥手:客户端收到了服务端对FIN的ACK后,进入FIN_WAIT2状态(等待服务端完成资源释放的一系列工作:然后释放你为创建这个连接所分配的资源,并通知我你关闭了); 客户端收到了服务端的FIN信令后,进入TIMED_WAIT状态,并发送ACK确认消息。客户端在TIMED_WAIT状态下,等待2MSL一段时间,没有数据到来的,就认为对面已经收到了自己发送的ACK并正确关闭了进入CLOSE状态,自己也断开了到服务端的TCP连接,释放所有资源。当服务端收到客户端的ACK回应后,会进入CLOSE状态,并关闭本端的会话接口,释放相应资源。TIME_WAIT状态持续2MSL(MSL是数据分节在网络中存活的最长时间)。

网络上比较主流的文章都说关闭TCP会话是四次挥手,但是实际上为了提高效率通常合并第二、三次的挥手,即三次挥手。

TCP流控制

​ 发送端根据自己的实际情况发送数据, 但是接收端可能收到的是一个毫无关系的数据包又可能会在处理其他问题上花费一些时间, 因此在为这个数据包做其他处理时会耗费一些时间, 甚至高符合的情况下无法接受任何数据, 如此一来, 如果接收端将本来应该接受的数据丢弃的话, 就又会出发重发机制, 导致网络流量的浪费.

​ 为了防止这种现象的发生, TCP提供了一种机制可以让发送端根据接收端的实际接收能力控制发送的数据量, 这就是所谓的流控制.

​ 接收端主机向发送端主机通知自己可以接收数据的大小, 于是发送端会发送不超过这个限度的数据, 该大小限度就被称为窗口大小, 窗口大小的值是由接收端主机决定的.

​ TCP首部中, 专门有一个字来通知窗口大小, 接收主机将自己可以接收的缓冲区大小放入这个字段忠同志发送端, 这个字段的值越大, 说明网络的吞吐量越高.

网络层

网络层负责处理网络中流动的数据包. 数据包是网络传输最小数据单位, 网络层规定了数据包通过怎样的路径(传输线路)到达对方的计算机. 并把数据包传给对方

IP地址是网络层及其以上层使用的地址

在这里插入图片描述

数据链路层

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

物理地址(MAC地址)是数据链路层和物理层使用的地址;

应用程序发出数据,这个数据经过上层一层层的封装,到达了数据链路层,在数据链路层做了Framing(成帧)处理.

太网上传输的数据在数据链路层以MAC帧(以太网帧格式)的形式存在, 最终会被转换为传输媒介UTP线缆上的电气信号. 电气信号转换
的过程中会根据不同的标准采用不同的编码方式.

以太网采用小端顺序方式来传输比特流, 也就是说对于1个字节的数据, 会从最低位开始传送, 在网络上进行传输的二进制数据所使用的的字节排列顺序也称为网络字节序. TCP协议中包括首部在内的均使用大端顺序传送数据

物理层

物理层会将这个数据帧转换成二进制信号(bit流)物理线路则只负责该数据以bit为单位从主机传输到下一个目的地

在物理层中, 将数据的0,1转换为电压传输给物理的传输介质, 而相互直连的设备之间使用地址实现传输, 这种地址成为MAC地址(Media Access Control 介质访问控制), 也可称为物理地址或硬件地址, 采用Mac地址, 目的是为了识别连接到同一个传输介质上的设备.

MAC地址和IP地址在标识一个通信主体时虽然都具有唯一性, 但是只有IP地址具有层次性

虽然MAC地址是真正负责最终通信的地址, 但在实际寻址过程中, IP地址却是必不可少

概念

路由器

可以再网络中转发数据包的设备.

路由器WAN口和LAN口各有一个MAC地址,WAN口MAC地址是对外通信的,LAN口地址是对内通信的。标准路由器上,每个端口各有 一个自己的MAC地址,以进行各网段的通信。

mac地址是由网络层的地址解析协议(ARP)完成的,主机ARP cache存放了本局域网上各主机和路由器的IP地址到硬件地址的映射表,并且这个表还动态更新。

当主机A要向本地局域网上的某台主机B发送数据包时, 就先在其ARP高速缓存中查看有无主机B的IP地址, 有的话就在ARP告诉缓存中查出其对应的硬件地址, 再把硬件地址写入MAC帧, 通过局域网把该MAC帧发往此硬件地址.

路由器中的路由表控制着数据包下一站发往的地址.

在这里插入图片描述

IP地址 & MAC地址

既然主机之间的连接最终通过MAC地址连接的为什么还要IP地址呢?

(1) ARP用来寻找同一个局域网中的主机,同一个局域网的ip地址的网络号相同。每个主机的ip地址并不固定,mac地址固定,最终归结于根据目标主机的mac地址寻找。

(2) 不同局域网的主机通信时,通过IP地址的网络号可以减少查找的次数,快速找到目标主机。

在这里插入图片描述

子网掩码

子网掩码是一个32位地址,用于屏蔽IP地址的一部分以区别网络标识和主机标识,并说明该IP地址是在局域网上,还是在远程网上

子网掩码不能单独存在,它必须结合IP地址一起使用。子网掩码只有一个作用,就是将某个IP地址划分成网络地址和主机地址两部分。

网段 & 广播

网段地址是主机号全为 0 的地址,表示某个网段,比如:网段地址 192.168.10.0/24 表示的是网络号为 192.168.10 的所有地址。

广播地址是主机号全为 1 的地址,向同一个网段中的所有主机发送数据包的一个地址,比如:网段地址 192.168.10.0/24 的广播地址是 192.168.10.255 。

MAC 地址是烧录到网卡上的,也叫硬件地址,可以标识某一台设备,但无法用来标识某一个网络区域。为了区分不同的网络区域,IP 地址闪亮登场。

网关

网关的工作机制和代理十分相似。而网关能使通信线路上的服务器提供非 HTTP 协议服务。

利用网关能提高通信的安全性,因为可以在客户端与网关之间的通信 线路上加密以确保连接的安全。比如,网关可以连接数据库,使用 SQL 语句查询数据。另外,在 Web 购物网站上进行信用卡结算时, 网关可以和信用卡结算系统联动。

全双工 & 半双工

单向通信(单工通信)——只能有一个方向的通信而没有反方向的交互。
双向交替通信(半双工通信)——通信的双方都可以发送信息,但不能双方同时发送(当然也就不能同时接收)。
双向同时通信(全双工通信)——通信的双方可以同时发送和接收信息。

调制解调器

调制解调器,是调制器和解调器的缩写 ,一种计算机硬件 [1] ,它能把计算机的数字信号翻译成可沿普通电话线传送的模拟信号,而这些模拟信号又可被线路另一端的另一个调制解调器接收,并译成计算机可懂的语言。这一简单过程完成了两台计算机间的通信。

所谓调制,就是把数字信号转换成电话线上传输的模拟信号;解调,即把模拟信号转换成数字信号。合称调制解调器。

在这里插入图片描述

传输速率

在数据传输的过程中, 两个设备之间的数据流动的物理速度成为传输速率, 单位为bps, 传输速率又称为带宽.

中继器

中继器: 由电缆传过来的电信号或者光信号经由中继器的波形调整和放大再传给另一个电缆

ICMP 控制报文协议

ICMP的主要功能包括: 确认IP包是否成功到达目标地址, 通知在发送过程中的IP包被废弃的具体原因, 改善网络设置等, 有了这些功能, 就可以获得网络是否正常, 设置是否有误以及设备有何异常信息等, 从而便于进行网络上的问题诊断

ICMP的消息大致可分为两类

  1. 一类是通知出错原因的错误消息,
  2. 一类是用于诊断的查询消息

网卡

层层辛辛苦苦的将包组装完成,但都是数字信息,我们需要转换为电信号或者光信号才能在网络上传输,这就网卡的作用。但是就当当的一块网卡能干啥,啥也干不了,他需要插上去并装上网卡驱动,计算机开机启动之时对网卡进行初始化才能开始使用。

网卡驱动从IP模块获取包之后,复制到网卡缓冲区,然后告知MAC层,MAC模块从缓冲区取出包并加上头部和起始帧,末尾加上帧校验序列

发送信号分为两种方式,一种是集线器方式,一种是交换机的全双工模式。

TCP粘包原因及解决方案

在TCP的socket编程中,发送端和接收端都有成对的socket。发送端为了将多个发往接收端的包,更加高效的的发给接收端,于是采用了优化算法(Nagle算法),将多次间隔较小、数据量较小的数据,合并成一个数据量大的数据块,然后进行封包。那么这样一来,接收端就必须使用高效科学的拆包机制来分辨这些数据。

在socket网络编程中,都是端到端通信,由客户端端口+服务端端口+客户端IP+服务端IP+传输协议组成的五元组可以明确的标识一条连接。在TCP的socket编程中,发送端和接收端都有成对的socket。发送端为了将多个发往接收端的包,更加高效的的发给接收端,于是采用了优化算法(Nagle算法),将多次间隔较小、数据量较小的数据,合并成一个数据量大的数据块,然后进行封包。那么这样一来,接收端就必须使用高效科学的拆包机制来分辨这些数据。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值