秋春招总结之计算机网络基础

前言

广告: 最近github上新开了一个仓库May-Nodes,包括但不限于之前面试遇到的相关数据库,计算机操作系统,Java基础知识,计算机网络以及LeetCode等算法题解等知识。届时也会整理学习使用的PDF文档与资源。有需要的小伙伴 可以点个关注和star。在持续更新中,总会遇到你想要的。
此篇文章是系列秋春招总结的第四篇,分为上下两篇,这篇文章主要会先具体讲解计算机网络的基础部分的架构系列,然后会对一些常出现的面试题目进行一个系统性的总结。

对于下一篇会主要对Http协议进行比较深入的剖析,讲解具体的Http协议与Https之间的难舍难分的关系

关于前三篇文章可以参见如下目录。

章节名称 文章地址
秋春招总结之MySQL MySQL
秋春招总结之Redis Redis
秋春招总结之并发多线程 并发多线程

最近也在进行其他系列的整理工作面试总结,包括但不限于LeetCodeSpring系列计算机操作系统计算机网络数据库Java基础,工具下载安装,届时也会整理学习使用的PDF文档与资源。有需要的小伙伴 可以点个关注和star。在持续更新中,总会遇到你想要的。

基础

OSI 七层参考模型

应用层

应用层是网络应用程序和网络协议存放的分层,因特网的应用层包括许多协议,例如我们学web离不开的HTTP,电子邮件传送协议SMTP、端系统文件上传协议FTP、还有为我们进行域名解析的DNS协议。应用层协议分布在多个端系统上,一个端系统应用程序与另外一个端系统应用程序交换信息分组,我们把位于应用层的信息分组称为报文(message)。

表示与会话

表示层主要包括数据压缩和数据加密以及数据描述,数据描述使得应用程序不必担心计算机内部存储格式的问题,。

会话层提供了数据交换的定界和同步功能,包括建立检查点和恢复方案。

传输层

维护的是端到端的连接,主要的两种不同的传输协议是TCPUDP 。但是却有很大的不同:

TCP:向它的应用程序提供了面向连接的服务,它能够控制并确认报文是否到达,并提供了拥塞机制和一些其他的方法来控制网络传输,因此当网络拥塞时或出现一些不可控的情况时候,会抑制其传输速率。

UDP:协议向它的应用程序提供了无连接服务。它不具备可靠性的特征,就是说提供的是不可靠的连接服务。没有流量控制,也没有拥塞控制。我们把运输层的分组称为报文段( segment)

网络层

负责将称为数据报的网络分层信息从一台主机移动到另外一台主机上。其上一个非常重要的协议是IP协议:所有具有网络层的因特网组件都必须运行IP协议,IP协议是一种网际协议,除了IP协议外,网络层还包括一些其他网际协议和路由选择协议,一般把网络层就称为IP层。

数据链路层

现在我们有应用程序通信的协议,有了给应用程序提供运输的协议,还有了用于约定发送位置的IP协议,那么如何才能真正的发送数据呢?

为了将分组从一个节点(主机或路由器)运输到另一个节点,网络层必须依靠链路层提供服务。链路层的例子包括以太网、WiFi和电缆接入的D0CSIS协议,因为数据从源目的地传送通常需要经过几条链路,一个数据包可能被沿途不同的链路层协议处理,我们把链路层的分组称为帧( frame)

物理层

虽然链路层的作用是将帧从一个端系统运输到另一个端系统,而物理层的作用是将帧中的一个个比特(也叫做比特流传输)从一个节点运输到另一个节点,物理层的协议仍然使用链路层协议,这些协议与实际的物理传输介质有关,例如,以太网有很多物理层协议:关于双绞铜线、关于同轴电缆、关于光纤等等。

各层与其对应的功能及协议

OSI七层模型 与TCP/IP对应 功能 协议族
应用层 应用层 文件传输,电子邮件,文件服务 DNS,Telnet,HTTP,FTP,SMTP
表示层 数据格式化,代码转换,数据加密
会话层 解除或建立与别的连接点的联系
传输 传输层 提供端对端的节点的联系 TCP UDP
网络层 网络层 (分组) 以数据包选择路由 IP ICMP RIP ICMP
数据链路 链路层 (帧)传输有地址的帧以及错误检测功能 PPP ARP RARP
物理层 (比特流) 二进制在物理媒体上传输数据 IEEE802

TCP/IP 五层参考模型

对应的每层的工作设备

什么是Http

首先对于Http来说是一个超文本传输协议(Hypertext Transfer Protocol),我们可以进行分割处理: 超文本(Hypertext )传输(Transfer)协议(Protocol)

什么是超文本

在互联网早期的时候,我们输入的信息只能保存在本地,无法和其他电脑进行交互。我们保存的信息通常都以文本即简单字符的形式存在,文本是一种能够被计算机解析的有意义的二进制数据包。而随着互联网的高速发展,两台电脑之间能够进行数据的传输后,人们不满足只能在两台电脑之间传输文字还想要传输图片、音频、视频,甚至点击文字或图片能够进行超链接的跳转,那么文本的语义就被扩大了,这种语义扩大后的文本就被称为超文本( Hypertext)

什么是传输

我们上面说到,两台计算机之间会形成互联关系进行通信,我们存储的超文本会被解析成为二进制数据包,由传输载体(例如同轴电缆,电话线,光缆)负责把二进制数据包由计算机终端传输到另一个终端的过程称为传输ransfer

什么是协议

就是在网络中(包括互联网)传递,管理信息的一些规范,我们人与人之间进行相互的交流是需要遵循一定的规矩,在计算机和计算机之间的相互通信需要共同遵守一定的规则,这些就被称为网络协议。

详解Http报文

对于Http协议主要由三大部分组成

  • 起始行(start line): 描述请求或响应的基本信息。
  • 头部字段(header): 使用到key-value 形式更详细说明报文;
  • 消息正文(entity): 实际上传输的数据,不一定是纯文本,还有可能是图片等。

对于Http协议规定:其中起始行和头部字段并成为请求头或者响应头,统称为Header;消息正文也叫做实体,称为body。

HTTP协议规定每次发送的报文必须要有 Header,但是可以没有body,也就是说头信息是必须的,实体信息可以没有。而且在 header和body之间必须要有一个空行(CRLF),下面来用一副图片来进行展示:

总结:Http是一个在计算机实践专门在两点之间传输文字,图片,音频,视频等超文本数据的约定和规范。

Http 请求的八种方式

  • GET获取资源,GET方法用来请求访问已被URL识别的资源。指定的资源经服务器端解析后返回响应内容。也就是说,如果请求的资源是文本,那就保持原样返回;

  • P0ST传输实体,虽然GET方法也可以传输主体信息,但是便于区分,我们一般不用GET传输实体信息,反而使用PosT传输实体信息

  • PUT传输文件,PUT方法用来传输文件。就像FTP协议的文件上传一样,要求在请求报文的主体中包含文件内容,然后保存到请求URL指定的位置。

  • 但是,鉴于HTTP的PUT方法自身不带验证机制,任何人都可以上传文件,存在安全性问题,因此一般的Web网站不使用该方法。若配合Web应用程序的验证机制,或架构设计采用REST( Representational State Transfer,表征状态转移)标准的同类Web网站,就可能会开放使用PUT方法。

  • HEAD获得响应首部,HEAD方法和GET方法一样,只是不返回报文主体部分。用于确认UR的有效性及资源更新的日期时间等。

  • DELETE删除文件, DELETE方法用来删除文件,是与PUT相反的方法。 DELETE方法按请求UR删除指定的资源。

  • OPTIONS询问支持的方法, OPTIONS方法用来查询针对请求UR指定的资源支持的方法。

  • TRACE追踪路径, TRACE方法是让web服务器端将之前的请求通信环回给客户端的方法。

  • CONNECT要求用隧道协议连接代理, CONNECT方法要求在与代理Posy务器通信时建立隧道,实现用隧道协议进行TCP通信。主要使用**SSL( Secure Sockets Layer,安全套接层)TLs( Transport Layer Security,**传输层安全)协议把通信内容加密后经网络隧道传输。

    Get和Post 的区别

分类 GET POST
后退按钮/刷新 无害 数据会被重新提交(浏览器也会告诉用户是否要重新提交数据)
书签 get请求可以被保留为书签 post请求不可以被保留为书签,因为post请求会在每一次的请求过程中提交新的数据
缓存 get请求重复输入网址时候,能够被缓存起来 不能够缓存
对长度的限制 有限制,当在发送数据时候,GET方法向URL添加数据;URL的长度是要受到限制(最大长度为2048个字符) 无限制
对数据类型的限制 只允许ASCII字符 没有限制。也允许二进制数据
安全性 对于post来说,安全性要低一点,因为对于get请求而言,URL地址在地址栏都是可见的 比get请求要安全一点,因为参数不会被保存在浏览器中,或者是web日志中
可见性 所有的URL在地址栏中都是可见的 数据不会显示在URL中,都是点击按钮以后,携带的数据,在后台中

所以综上所述:
GET: 用于浏览器地址栏输入URL时候获取信息,是无副作用的,且可缓存下来下次使用。日常所用的地址收藏的都是get请求。
POST:用于修改数据,有副作用,非幂等,不可缓存下来(因为数据在不断的变化)

为什么会有长度的限制

我们知道的是并不是说对于get请求的限制有多强制。对于HTTP协议而言,其BodyHelder并没有一个限制,对于URL进行限制主要是由于浏览器和服务器的原因,对于浏览器来说每个不同的浏览器的get请求的长度也是不同的。对于服务器来说,在处理URL时候需要消耗较多的资源。为了性能和安全起见(也是为了防止恶意构造长URL来攻击)考虑。因此一般都会说对与get请求来言。有一个长度的限制。

Http的各种状态码表示什么意思

  • 100 指向信息 表示请求已接收 继续处理

  • 101 客户端要求服务器根据请求转换 HTTP协议版本

  • 2xx 成功 表示请求已经被接收 理解 接收

  • 3xx 重定向 信息不完整需要进行一步补充

  • 301 永久重定向

  • 302 临时重定向

  • not Modified 请求的资源没有改变 可以继续使用缓存。
    4xx 客户端错误 有语法错误 或请求无法实现

  • 401 未授权

  • 403 禁止访问

  • 404 没有发现对应的文件
    5xx 服务端 服务端未能实现合法

  • 500 内部服务错误

  • 502 网关错误

  • 503 服务不可用

  • 504 网关超时。

Http1.0,1.1,2.0 之间的区别

1.0版本

  • HTTP1.0仅仅提供了最基本的认证,这时候用户名和密码还未经加密,因此很容易收到窥探。

  • HTTP1.0被设计用来使用短链接,即每次发送数据都会经过TCP的三次握手和四次挥手,效率比较低。

  • HTTP1.0不支持断点续传,也就是说,每次都会传送全部的页面和数据。

  • HTTP1.0认为每台计算机只能绑定一个|P,所以请求消息中的∪RL并没有传递主机名( hostname)。

1.1版本

  • HTTP1.1使用了摘要算法来进行身份验证
  • HTTP1.1默认使用长连接,长连接就是只需一次建立就可以传输多次数据,传输完成后,只需要次切断连接即可。长连接的连接时长可以通过请求头中的keep- alive来设置HTTP
  • HTTP1.1支持断点续传,通过使用请求头中的Range来实现
  • HTP1.1使用了虚拟网络,在一台物理服务器上可以存在多个虚拟主机(Muti- homed WebServers),并且它们共享一个P地址。

差别:支持长连接和增加了虚拟主机的功能

2.0 版本

  • 头部压缩,由于HTP1.1经常会出现User- Agent、 Cookie、 Accept、 Server、 Range等字段可能会占用几百甚至几千字节,而Body却经常只有几十字节,所以导致头部偏重。HTTP2.0使用 HPACK算法进行压缩。
  • 二进制格式,HTP2.0使用了更加靠近TCP/P的二进制格式,而拋弃了ASCII码,提升了解析效率
  • 强化安全,由于安全已经成为重中之重,所以HTTP2.0一般都跑在HTPS上。
  • 多路复用,即每一个请求都是是用作连接共享。一个请求对应一个id,这样一个连接上可以有多个请求。

TCP与UDP的区别

UDP 是什么

UDP的全称是 User Datagram Protocol,用户数据报协议。它不需要所谓的握手操作,从而加快了通信速度,允许网络上的其他主机在接收方同意通信之前进行数据传输

数据报是与分组交换网络关联的传输单元

UDP的特点:

  • UDP能够支持容忍数据包丢失的带宽密集型应用程序
  • UDP具有低延迟的特点
  • UDP能够发送大量的数据包
  • UDP能够允许DNS查找,DNS是建立在UDP之上的应用层协议。

TCP 是什么

TCP的全称是 Transmission〔 ontrol Protocol,传输控制协议。它能够帮助你确定计算机连接到 nternet以及它们之间的数据传输。通过三次握手来建立TCP连接,三次握手就是用来启动和确认CP连接的过程连接建立后,就可以发送数据了,当数据传输完成后,会通过关闭虚拟电路来断开连接。

TCP的主要特点有:

  • TCP能够确保连接的建立和数据包的发送
  • TCP支持错误重传机制T
  • CP支持拥塞控制,能够在网络拥堵的情况下延迟发送
  • TCP能够提供错误校验和,甄别有害的数据包

不同之处

TCP UDP
是面向连接的协议 无连接的协议
在发送数据之前需要建立连接,然后才能够发送数据 无需建立连接就可以发送大量的数据
会按照特点顺序重新排列数据包 数据包没有固定的顺序,所有数据包都是相互独立的
头部字节有20个字节 头部字节只有8个字节
是重量级的,在发送任何用户数据之前,都需要进行三次握手 是轻量级的,没有跟踪连接,消息排序等
会进行错误校检 也有错误检查,但是会丢弃错误的数据报
会使用握手协议,例如 SYN,SYN-ACK ACK等 无握手协议
是可靠的,因为它可以确保将数据传送到路由器 不能够保证数据安全到达目标

是如何保证数据传输的可靠性的

  1. 将应用数据分割成TCP认为最合适发送的数据块,
  2. TCP会保持它首部和数据的检验和,是一个端到端的检验和,目的是检验数据在传输的过程中有没有发生变化。
  3. 超时重传 在TCP发出一个数据后,它启动一个定时器,等待目的端确认收到这个报文段,如果不能及时得到一个确认,将重发这个报文段。在未收到确认之前,这些已经发送的数据报将留在发送缓冲区,直到收到确认之后才清除已发送的数据.
  4. 提供流量控制,TCP连接的每一方都有固定大小的缓冲空间,TCP连接的另外一端只允许发送接收端缓冲区所能够容纳的数据。这将防止较快主机致使较慢主机的缓冲区溢出
  5. 对接受到的信息进行重排序 因为在传输的过程中,可能会出现失序情况,这个时候将数据进行重排序,将收到的数据以正确的顺序交给应用层。
  6. 拥塞控制:发送发维持一个叫做拥塞窗口的状态变量,拥塞窗口的大小取决于网络的拥塞程度,并且使动态变化的,发送方让自己的发送窗口等于拥塞窗口。发送方的原则是 只要网络没有出现阻塞,拥塞窗口就会增大一点以便把更多的分组发送出去,网络出现问题,就会把窗口减少一点,以减少注入到网络中的分组数。。。

三次握手与四次握手

三次

  1. 首先对于 TCP服务端进程先创建传输控制块TCB,进入到接受客户端进程的连接请求的状态,

  2. 此时TCP的客户端也是先创建传输控制块TCB,然后向服务端发送连接请求报文,报文中首部的同部位SYN=1,同时选择初始化序列号seq=x,此时客户端就进入到SYN-SENT(同步信息以发送的状态)。

  3. TCP的服务端在接收到请求以后,如果同意建立连接,发出确认连接报文,报文中的 SYN=1,ACK=1,确认号ack=x+1,同时也要初始化一个自己的序列号seq=y,然后进入到SYN-RCVD(同步接收状态) 。

  4. TCP客户端在接收到服务端发送的确认信息以后 还要向服务端再次发送一个确认信息,ACK=1,ack=y+1.服务端的序列号为 seq=x+1 建立连接以后 ,客户端进入到ESTABLISHED(已建立连接状态)服务端也进入到相同的状态 开始通信

为什么要三次握手,而不是两次

假设有这样一种场景,客户端发送了第一个请求连接并且没有丢失,只是因为在网络结点中滞留的时间太长了,由于TCP的客户端迟迟没有收到确认报文,以为服务器没有收到,此时重新向服务器发送这条报文,此后客户端和服务器经过两次握手完成连接,传输数据,然后关闭连接。

此时此前滞留的那一次请求连接,网络通畅了到达了服务器,这个报文本该是失效的,但是,两次握手的机制将会让客户端和服务器再次建立连接,这将导致不必要的错误和资源的浪费。
如果采用的是三次握手,就算是那一次失效的报文传送过来了,服务端接受到了那条失效报文并且回复了确认报文,但是客户端不会再次发出确认。由于服务器收不到确认,就知道客户端并没有请求连接。

四次挥手

在完成了通信双发的通信以后 两方都可以进行连接的释放,最开始时候 客户端与服务端都是处于 ESTABLISHED 的状态 然后1客户端主动关闭 服务端被动关闭

  1. 客户端发送连接释放报文,释放报文数据首部,FIN=1,序列号seq=u(等于前面已经传过来的数据的最后一个字节加上一),然后进入到FIN-WAIT (终止等待-1)。
  2. 服务端接收到连接释放报文,发出确认报文ACK=1,ack=u+1。并带上自己的序列号 seq=v;此时进入到CLOSE-wait(关闭等待)状态。这个时候 服务端向客户端发送信息客户端还是会接收 但是客户端不会向服务端发送数据。
  3. 客户端在接收到服务端的确认信息以后 进入到 FIN-WAIT
    (终止等待2) 等待服务器发送连接释放报文。
  4. 服务端将最后的数据都发送完成以后 向客户端发送连接释放报文发出确认号 ACK=1,ack=u+1,此时可能期间还发送了一些其他的数据 此时的seq序列号为w,发送完成以后 就进入到 LAST-ACK(最后确认的状态)
  5. 客户端接收到连接释放以后 发出 ACK=1 ack=w+1,自己的序列号 seq=u+1,就进入到TIME-wait状态 。但是此时并没有真正的释放 必须经过2* MSL(最长报文段寿命时间) 才会撤销TCB进入到close状态。
  6. 服务器端收到客户端发出的确认立即进入到 closed 状态 同时撤销TCB 结束连接

为什么要等待2* MS

对于 TCP来说 运行不同的实现可以设置不同的MSL值。

  1. 保证客户端最后发送的ACK报文能够到达服务器 因为这个报文很有可能会丢失 。我们此时站在服务器的角度来看 我已经发送了FIN+ACK报文请求断开了 但是客户端没有给我回应 ,所以会重新发送断开连接的报文 这个时候 客户端还没有完全关闭 收到以后 就会再发送报文给服务器端 并立马重启2MSL计时器
  2. 防止出现 三次握手时候 出现的 防止失效的连接请求报文段出现在本连接中 ,客户端发送最后一个确认报文以后 在这个实践里面 就可以使得本连接持续实践内所产生的所有报文都从网络中 消失 这样新的连接里面就不会出现旧连接的请求报文。

为什么连接时候是三次 关闭连接却是四次握手

建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次

## Servlet 中 forward与 redirect的区别

通常我们在设计web应用程序的时候,需要把一个系统进行结构化的设计,按照模块进行划分,不同的servlet实现不同的功能。一个实现接受用户的请求,一个实现处理请求。需要在两个servlet之间进行跳转。
forward是服务器内部的定向使用,服务器直接访问目标地址的url,把那个URL的响应内容读取过来,但是在客户端并不知道这些变化,在客户端的浏览器中也不会显示后来forward的地址信息,客户端的请求还是同一个请求,请求的地址还是原来的地址,在整个的定向的过程中使用到的是同一个request。
redirect 是客户端的重定向信息,是完全的跳转,在用户输入一个URL时候,逻辑执行完成以后就会跳转到新的地址,这个时候也会重新发送一个新的请求,在浏览器中显示的也是新的URL地址信息,由于比forward 多增加一个网络的请求 所以效率要低一些。

一个网页从开始请求到最后显示的过程

一般会经过七个步骤:

  1. 在浏览器中输入地址。此时会先从浏览器中查找对应的ip地址 如果没有找到 从hosts文件查找 没有 路由器缓存 DNS 缓存
  2. 发送到DNS服务器并获得域名对应的WEB服务器的IP地址(递归查询)。
  3. 与Web服务器建立TCP连接。
  4. 浏览器向Web服务器的ip地址发送相对应的HTTP请求。
  • 应用层发送http请求,
  • 创输层的TCP协议为传输报文提供可靠的字节流服务 (TCP三次握手)
  • 网络层把TCP分割好的各种数据包发送给接收方,使用到的是mac地址进行发送
  • 然后是链路层将数据发送到数据链路层传输到此客户端方法哦是那个连接请求完成
  1. Web服务器响应请求并返回指定的Url地址,或错误信息。如果设置重定向,则重定向到的新的URL地址。
  2. 浏览器下载数据,后解析HTML源文件,解析的过程中实现对页面的排版,解析完成以后在浏览器中显示基础页面。
  3. 分析页面中的超链接并显示当前页面,重复以上的过程直至无超链接需要发送,完成全部的显示。

猜你喜欢

转载自blog.csdn.net/weixin_44015043/article/details/107946812