计算机网络 - 面试准备

企业开发 2023-06-05 03:41:37 阅读次数: 0

计算机网络

OSI 七层模型

在这里插入图片描述

物理层

数据以比特流的形式在物理层传输
设备有中继器、集线器（作用：转发、放大信号）

数据链路层

负责将数据组帧，实现链路管理、流量控制和差错控制
协议有GBN后退N帧协议、SR选择重传协议、以太网协议
设备有网桥、交换机（作用：根据MAC地址对帧进行过滤转发，可以隔绝冲突域，不能隔绝广播域）
冲突域：同一时间内只能有一台设备发送信息的范围
广播域：网络中能接收到任意设备发出的广播帧的设备的集合

网络层

提供主机和主机之间的逻辑通信
协议有ARP协议、OSPF/RIP路由寻址协议、DHCP协议、ICMP协议、IGMP组播协议、IP协议、CIDR协议
设备有路由器（作用：转发分组）

传输层

提供端到端的可靠报文传递，负责将数据传送至对应端口，提供进程和进程之间的逻辑通信
协议有TCP UDP协议

会话层

负责建立、管理、终止进程之间的会话

表示层

对上层数据或者信息进行变换，以保证一个主机应用层信息可以被另一个主机应用层所理解，包括数据加密、格式转换、压缩等

应用层

为操作系统或者网络应用程序提供访问网络的接口 协议有HTTP FTP SMTP DNS协议

TCP/IP 四层模型

在这里插入图片描述
在这里插入图片描述

地址

在这里插入图片描述

  • A类地址：以0开头， 第一个字节范围：0~127（1.0.0.0 - 126.255.255.255）
  • B类地址：以10开头， 第一个字节范围：128~191（128.0.0.0 - 191.255.255.255）
  • C类地址：以110开头， 第一个字节范围：192~223（192.0.0.0 - 223.255.255.255）
  • 10.0.0.0—10.255.255.255， 172.16.0.0—172.31.255.255， 192.168.0.0—192.168.255.255。（Internet上保留地址用于内部）
  • ipv6：128bit，16进制

http常见状态码

  • 1xx 通知
    • 100 continue 表示出的请求已经被服务器接收，游览器应当继续发送请求的其余部分（HTTP1.1）（http报文中如果有post方法的话 会先把请求行发送过去，然后返回100，然后再发送请求头部和请求体给服务器端）
    • 101 switching pototcols 服务器将遵从客户的请求转换到另外一种协议（HTTP1.1）。
  • 2xx 成功
    • 200 OK 一切正常返回数据
    • 201 created 服务器已经创建了文档，location 头给出了他的URL。
    • 202 accepted 已经接收请求，但是尚未处理完成。
    • 203 non-authoritative information 文档已经正常的返回，但一些应答头可能不正确，因为使用的是的文档的拷贝(HTTP 1.1新)。
    • 204 No content 请求正常处理，但是没有数据返回
    • 206 指定范围返回（http1.1以上支持的断点续传功能相关）
  • 3xx 重定向
    • 301 永久性重定向：再也不用了
    • 302 Found 类似301，但新的URL应该被视为临时性的替代，而不是永久性的，注意，在HTTP1.0中对应的状态信息moved Temporatily。出现该状态码，浏览器能够给自动访问新的URL，因此他是一个很有用的状态代码。
    • 303 暂时性重定向 但是服务器端明确说明希望浏览器用get方法来请求资源
    • 304 浏览器附带了请求的条件，服务器端允许访问，但是不满足请求条件
  • 4xx 客户端错误
    • 400 客户端的请求有语法错误
    • 401 unauthorized 客户试图未经授权访问受密码保护的页面。应答中会包含-WWW-Authenticate头，浏览器据此显示用户名字和密码对话框，然后再填写合适的authorization头后再次发送请求。
    • 403 Forbidden 资源不可用。服务器理解客户的需求，但是拒绝处理他通常由于服务器上文件或目录的权限设置问题。
    • 404 Not found 客户端申请访问的资源不存在
    • 405 Method not allowed 客户端请求方法被禁止
  • 5XX 服务端错误
    • 500 internal Server Error 服务器遇到了意料不到的情况，不能完成客户的请求
    • 501 Not lmplemented 服务器不支持请求所需要的功能。例如，客户发出来了一个服务器不支持的put请求。
    • 502Bad Gateway 服务器作为网关或者代理时，为了完成请求访问下一个服务器，但该服务器返回了非法的应答。
    • 503 service unavilable 服务器由于维护或者负载过重未能应答。例如，servlet 可能在数据库连接池已满的情况下返回503.服务器返回503时可以提供一个retry-after头。
    • 504 gateway timeout 作为代理或网关服务器使用，表示不能及时的从远程服务器获得应答（HTTP 1.1新）
    • 505 HTTPversion not supported 服务器不支持请求中所指明的HTTP版本。（HTTP 1.1新）

常见应用端口

在这里插入图片描述

  • DNS：53
  • Shell/cmd:514
  • Apache:8080
  • Flask默认:5000

http,https,socket

  • HTTP全称是HyperText Transfer Protocal，即：超文本传输协议，HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。
    • GET：对服务器资源的简单请求
    • POST：用于发送包含用户提交数据的请求
      • GET请求的数据会附在URL后面，POST的数据放在HTTP包体
      • POST安全性比GET安全性高
    • HEAD：类似于GET请求，不过返回的响应中没有具体内容，用于获取报头
    • PUT：传说中请求文档的一个版本
    • DELETE：发出一个删除指定文档的请求
    • TRACE：发送一个请求副本，以跟踪其处理进程
    • OPTIONS：返回所有可用的方法，检查服务器支持哪些方法
    • CONNECT：用于ssl隧道的基于代理的请求
  • HTTPS是HTTP over SSL/TLS，HTTP是应用层协议，TCP是传输层协议，在应用层和传输层之间，增加了一个安全套接层SSL/TLS：
    • SSL (Secure Socket Layer，安全套接字层)
    • TLS (Transport Layer Security，传输层安全协议)
    • SSL使用40 位关键字作为RC4流加密算法（对称加密算法）
  • socket只是一种连接模式，不是协议，socket是对TCP/IP协议的封装，Socket本身并不是协议，而是一个调用接口（API），通过Socket，我们才能使用TCP/IP协议。tcp、udp，简单的说（虽然不准确）是两个最基本的协议，很多其它协议都是基于这两个协议如，http就是基于tcp的，用socket可以创建tcp连接，也可以创建udp连接，这意味着，用socket可以创建任何协议的连接，因为其它协议都是基于此的。
  • 如何标记http：socket四元组

GET和POST

  • 注意存放在请求行和请求体的不是方法 而是请求/提交的数据， post和get方法都是在请求行中啦
  1. get数据明文存放在http请求行的url之后，post则是将提交的数据放在http请求报文的请求体中
  2. 受浏览器对url长度的限制，get传送数据量应不超过2KB。post传送数据量则一般无此限制
  3. get只接受acsii字符，post没有限制，get只支持url编码，post没有限制
  4. get不能改变服务器的数据，一般用于从服务器获取数据，是幂等的；post可以改变服务器的数据，不是幂等的。（从定义上看，HTTP方法的幂等性是指一次和多次请求某一个资源应该具有同样的副作用）
  5. get请求可以被浏览器主动缓存，下一次若传输数据相同，则优先返回缓存中的内容，以加快显示速度。post请求不会，除非手动设置一下
  6. get请求参数会被完整地保存在浏览器历史记录中，post请求参数则不会保留

cookie和session

  • session可以和cookie是同一层的实体概念，也可以指抽象的一对一的身份认证功能的抽象描述。从抽象的session来看，cookie可以算是抽象session的一种实现。当然，我们主要讨论的是两种实体之间的联系。
  • 首先它们都是用于给无连接的http提供身份认证的功能
  • cookie是服务器在本机存放的小段文本，并随每一个请求发送至同一服务器。cookie分为会话cookie（不设置过期时间，关闭浏览器窗口cookie即失效，保存在内存中）和持久cookie（设置过期时间，关闭再打开浏览器cookie仍存在，直至达到过期时间）。类似于检查通行证（即请求报文中附带的cookie）来确定用户身份
  • session则一般是利用session id实现的（session id是浏览器第一次发送请求时服务器自动生成的唯一标识，并返回给浏览器），cookie中携带该session id，客户端根据该session id将session检索出来。类似于在服务器上建立一个客户档案，客户来访时需要查询客户档案
  • cookie是存放在客户端，用于记录用户信息的，比如自动填充用户名和密码；session是存放在服务器端的，用于记录用户的状态，比如购物车的实现。
  • cookie不太安全，可以分析存放在本地的cookie进行cookie欺骗，（也可以用加密算法加密后进行存放），session存放于服务器的内存中，所以安全性高
  • 单个cookie保存数据不能超过4k，session没有对存储数据量的限制
  • 禁掉cookie的话session仍然可以使用，但是需要使用其他方法获取session id，比如在url后面或者以表单的形式提交给服务器端

IP与MAC ：他们能互相替代吗

  • MAC地址是网络中每个设备都有的唯一网络标识，全世界唯一。
  • IP地址只是逻辑上的标识，任何人都能随意修改，因此不能具体标识一个用户，但MAC地址固化在网卡里，防止被盗用。
  • 但是如果只用MAC地址的话，因为MAC地址无序杂乱，没有明显规则，难以查找。但是IP是分层的，类似通讯地址，可以根据其网络号找到子网再定义主机，逐级查找，每个设备需要存储的信息较少
  • MAC地址与IP地址的区别：
    ①长度不同，IP地址一般为32位（IPv6 128位），MAC地址则是48位
    ②分配依据不同，IP地址分配基于网络拓扑，能够根据需要改动设备的IP地址，但是MAC地址的分配是基于制造商，在网卡中烧录好，一般不轻易改变
    ③寻址协议层不同，IP地址应用于网络层，MAC地址应用于数据链路层（数据链路层基于MAC地址转发数据帧，数据链路层的交换机根据其MAC地址记录表中的MAC地址及其对应的端口，将其发送到MAC地址对应的端口，否则广播；网络层则根据IP地址转发报文，路由器根据路由表转发到对应端口，否则发送默认路由）

ARP

  • 作用：实现IP地址到MAC地址的映射（由IP地址获得MAC地址）
  • 流程：根据主机A路由表的内容查找B的IP地址，再从A的ARP高速缓存中寻找是否有B的MAC地址，如果没有则广播ARP请求帧（构成为Aip+Bip+A_MAC+全1）至该局域网内所有的主机。如果主机发现该请求帧中的IP地址与自己的相同则返回一个单播ARP帧（构成为Bip+B_MAC)返回给主机A，并且AB均更新自己的ARP高速缓存。

DNS：域名与IP / DNS劫持

  • 当DNS客户机需要在程序中使用名称时，它会查询DNS服务器来解析该名称。客户机发送的每条查询信息包括三条信息：包括：指定的DNS域名，指定的查询类型，DNS域名的指定类别。
  • 基于UDP服务，端口53. 该应用一般不直接为用户使用，而是为其他应用服务，如HTTP，SMTP等在其中需要完成主机名到IP地址的转换。
  • DNS劫持也可以理解为用户的请求去往了错误的DNS服务器进行查询解析，返回来的目的主机IP自然不是我们想要达到的资源服务器主机。当然，如果DNS服务器有意将解析地址引到其他缓存，或者为了广告收益将解析地址指向广告网站，这也可能是劫持的原因。

NAT：内外网

  • NAT路由器上将其本地地址转换成全球IP地址

浏览器请求网页全过程 / http全流程

在这里插入图片描述

  • 对网址进行DNS域名解析，得到对应的IP地址

  • 根据这个IP，找到对应的服务器，发起TCP的三次握手

  • 建立TCP连接后发起HTTP请求

  • 服务器响应HTTP请求，浏览器得到html代码

  • 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等）（先得到html代码，才能去找这些资源）

  • 浏览器对页面进行渲染呈现给用户

  • 服务器关闭关闭TCP连接或者保持连接keep-alive

  • 注：

    • DNS怎么找到域名的？
      • DNS域名解析采用的是递归查询的方式，过程是，先去找DNS缓存->缓存找不到就去找根域名服务器->根域名又会去找下一级，这样递归查找之后，找到了，给我们的web浏览器
    • 为什么HTTP协议要基于TCP来实现？
      • TCP是一个端到端的可靠的面相连接的协议，HTTP基于传输层TCP协议不用担心数据传输的各种问题（当发生错误时，会重传）
    • 最后一步浏览器是如何对页面进行渲染的？
      • 解析html文件构成 DOM树
      • 解析CSS文件构成渲染树
      • 边解析，边渲染
      • JS 单线程运行，JS有可能修改DOM结构，意味着JS执行完成前，后续所有资源的下载是没有必要的，所以JS是单线程，会阻塞后续资源下载

TCP/UDP

  • TCP是一种可靠的、面向连接的字节流服务。源主机在传送数据前需要先和目标主机建立连接。然后，在此连接上，被编号的数据段按序收发。同时，要求对每个数据段进行确认，保证了可靠性。如果在指定的时间内没有收到目标主机对所发数据段的确认，源主机将再次发送该数据段。
  • UDP：UDP是一种不可靠的、无连接的数据报服务。源主机在传送数据前不需要和目标主机建立连接。数据被冠以源、目标端口号等UDP报头字段后直接发往目的主机。这时，每个数据段的可靠性依靠上层协议来保证。在传送数据较少、较小的情况下，UDP比TCP更加高效。（面向字符流，不限长度，以包的形式传输，没有拥塞控制）
  • 报文段
    在这里插入图片描述
    在这里插入图片描述
  • IP数据报格式
    在这里插入图片描述

TCP三次握手

  • 原因：确保双方间的连接正常建立，如果只有两次握手的话可能会出现一些异常情况，比如：
    • ①客户端的SYN连接请求失效(或者发去时间太久,导致了超时重传的发生)，但是服务器端接收到了该SYN报文，如果不经过第三次握手的话服务器端就会错误地开启一个连接；
    • ②如果只有两次握手地话，服务器端返回给客户端的确认报文丢失，会导致客户端因为没有收到确认所以关闭了该连接，但服务器端此时已做好了连接准备，造成资源的浪费
  • 第一次握手：客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；
  • 第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
  • 第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
  • 握手过程中传送的包里不包含数据，三次握手完毕后，客户端与服务器才正式开始传送数据。理想状态下，TCP连接一旦建立，在通信双方中的任何一方主动关闭连接之前，TCP 连接都将被一直保持下去。

TCP SYN攻击

  • 攻击者伪装成客户端发送TCP的SYN报文, 当服务器返回ACK确认报文之后, 攻击者不再进行确认, 即不回复确认的确认报文, 这个连接就处于一个挂起的状态, 服务器收不到确认报文的话, 会启用超时重传机制, 重复发送ACK给攻击者
  • 这样的话,如果攻击者开启大量这种TCP连接, 导致服务器端有很多个挂起的连接, 并且需要重复发送很多ACK给攻击者, 这样就会消耗服务器的内存 可能导致最后服务器死机, 无法正常工作
  • 解决方法：
    • 降低SYN timeout时间 使得服务器在没收到确认报文后尽快释放半连接的占用
    • 采用SYN cookie设置 给每一个请求连接的ip地址分配一个cookie,短时间内如果连续收到某个IP的重复的SYN报文,就认定收到了攻击,以后会自动丢弃该ip地址传送过来的包

TCP四次握手

  • 与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。原因：
    • 因为建立连接时双方都处于closed状态，而释放连接时一方收到FIN报文但有可能还有数据要继续传输，不能马上释放连接，所以先返回一个确认报文，发送完数据后再断开连接
  • 第一次挥手：主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。（半关闭状态）
  • 第二次挥手：被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。
  • 第三次挥手：被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。
  • 第四次挥手：主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。
  • 请求关闭方在TIME-WAIT状态等待2MSL的原因 ：确认服务器端是否正常收到了客户端最后发出的确认报文，如果服务器端没有收到的话，过1MSL（报文在网络中的最大存活时间）会重新再发送一次FIN报文给客户端，如果过了2MSL还没有收到新发的FIN报文的话，证明服务器端已经收到确认报文并正常关闭连接，客户端也可以关闭连接啦~

TCP可靠性保证

  1. 分段 将报文段分成适合转发的长度
  2. 标号 按照序号判断中间的转发是否有缺失
  3. 流量控制 根据双方的接收发送能力，动态地调整发送方发送窗口的大小，取发送窗口=min(拥塞窗口，接收窗口) （与数据链路层收不下的话返回一个信号告诉发送方自己收不下的流量控制机制不同）
  4. 检验和 TCP首部有检验和字段，目的是检验首部+数据部分的数据是否正确，是不是被人篡改或半路出现差错。
  5. 超时重传 发出报文段之后启动定时器，如果重传时间RTT内没有收到确认的话，就重传该数据报，也可以采用冗余确认机制（三次接收到同一个ack=k的确认序号，就重传第k个报文段）（快重传中采用的也是冗余重传）。主要涉及的协议有两种（跟数据链路层的超时重传机制相同）：
    • 停止等待协议 每发送一个报文段就停止，直到收到确认才继续发送，否则超时重传
    • 滑动窗口协议：
      • 后退N帧协议 GBN： 发送窗口>1，接收窗口=1，即接收方必须按照顺序去接收数据，如果启用了超时重传机制的话，就会重传所有当前已经发送但是没有被确认的报文段
      • 选择重传协议 SR： 发送窗口>1，接收窗口>1，即接收方无需按照顺序去接收数据，会按照任意顺序接收所有处于接收窗口内的数据。按照如果启用超时重传机制的话只需要重新发送没有收到确认的数据即可。
  6. 拥塞避免 分为两种：①慢开始，拥塞避免 ②快重传、快恢复

拥塞控制

在这里插入图片描述

  • 慢开始/拥塞避免/快重传/快恢复
    • 当cwnd<ssthresh时，使用慢开始算法。
    • 当cwnd>ssthresh时，改用拥塞避免算法。
    • 当cwnd=ssthresh时，慢开始与拥塞避免算法任意
  • 慢开始：cwnd以字节为单位
    • cwnd=cwnd*2
    • 当cwnd>ssthresh时，改用拥塞避免算法。
  • 拥塞避免：
    • cwnd=cwnd+1
  • 超时：
    • ssthresh=cwnd/2
    • cwnd=1
  • 接收方连续传给发送方三个ACK（丢失报文）：
    • 快重传/快恢复
    • ssthresh=cwnd/2
    • cwnd=ssthresh
    • 也就是说开始拥塞避免

猜你喜欢

转载自blog.csdn.net/qq_42739587/article/details/115934460
今日推荐
面壁智能发布 Eurux-8x22B 开源大模型 —— 堪称「理科状元」
开源日报 | 谷歌扶持鸿蒙上位；开源Rabbit R1；Docker加持的安卓手机；微软的焦虑和野心；海尔电器把开放平台关了
中国码农的“35岁魔咒”
蘭雅 CorelDRAW 插件 2024.5.1 国际劳动节版，免费下载
Arc Browser for Windows 1.0 正式 GA
90后程序员开发视频搬运软件、不到一年获利超 700 万，结局很刑！
周排行
【转】spring中对控制反转和依赖注入的理解
tms webcore 安装和使用
java程序员进阶相关书籍
SpringMVC接受请求参数、
如何保存训练好的机器学习模型
MyEclipse、Eclipse设置项目JDK的三个地方
商超行业微信小程序开发定制一般多少钱 （行业技术人员解读）
Markdown编辑器语言——30分钟入门到到精通
Linux系统下MongoDB的简单安装与基本操作
Power Strings
每日归档
更多
2024-05-07(14)
2024-05-06(40)
2024-05-05(0)
2024-05-04(7)
2024-05-03(19)
2024-05-02(0)
2024-05-01(4)
2024-04-30(1)
2024-04-29(40)
2024-04-28(0)

代码天地 © 2018 codetd.com

境外服务器   最新电视剧2022