计算机网络
计算机网络
网络分层结构
计算机网络体系大致分为三种,OSI七层模型、TCP/IP四层模型和五层模型。
TCP/IP五层模型:应用层、传输层、网络层、数据链路层、物理层。
OSI七层模型:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
TCP/IP四层模型:应用层、传输层、网络层、数据链路层。
-
应用层:为应用程序提供交互服务。在互联网中的应用层协议很多,如域名系统DNS、HTTP协议、SMTP协议等。
-
传输层:负责向两台主机进程之间的通信提供数据传输服务。传输层的协议主要有传输控制协议TCP和用户数据协议UDP。由于一个主机可同时运行多个进程,因此传输层有复用和分用的功能。
- 复用:就是多个应用层进程可同时使用下面传输层的服务。
- 分用:就是把收到的信息分别交付给上面应用层中相应的进程。
-
网络层:选择合适的路由和交换结点,确保数据及时传送。主要包括IP协议。
-
负责为网络上的不同主机提供通信服务。在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组或包进行传送。在TCP/IP体系中,由于网络层使用IP协议,因此分组也叫做IP数据报,或简称为数据报。
-
选择合适的路由,使源主机运输层所传下来的分组,能够通过路由器找到目的主机。
-
-
数据链路层:在两个相邻节点之间传送数据时,数据链路层将网络层交下来的 IP 数据报组装成帧,在两个相邻节点间的链路上传送帧。
- 链路层协议:点对点协议(PPP)。
- 链路层设备:网桥(对收到的帧根据其MAC帧的目的地址进行转发和过滤)、交换机(独占传输媒体,无碰撞地传输数据)。
-
物理层:实现相邻节点间比特流的透明传输,尽可能屏蔽传输介质和物理设备的差异。
- 物理层设备:中继器(再生数字信号)、集线器(对信号进行再生放大转发)。都是来增加信号传输距离,延长网络的长度。
TCP三次握手
三次握手是用于建立连接。
三次握手:
①客户端向服务端发送连接请求报文段,状态变为SYN-SENT
。
②服务端收到连接请求报文段后,发送一个确认应答, 状态变为SYN_RCVD
。
③客户端收到服务端连接同意的应答后,还会向服务端发送一个确认报文段,表示服务端发来的连接同意应答已经成功收到。第三次握手后客户端和服务端的状态都为ESTABLISHED
为什么不是两次握手?
为了防止已失效的连接请求报文段突然又传送到了服务端,造成服务端资源的浪费。
四次挥手
四次握手是用于释放连接。
四次挥手:
①客户端数据发送完成,则它向服务端发送连接释放请求,进入FIN-WAIT-1
(终止等待1)状态。
②服务器收到客户端连接释放报文,发出确认报文段,进入CLOSE-WAIT
(关闭等待)状态,此时的TCP处于半关闭状态,客户端向服务器这个方向的连接就释放了。
③客户端收到确认后,进入FIN-WAIT-2
(终止等待2)状态。服务端将最后的数据发送完毕后,就向客户端发送连接释放报文,进入LAST-ACK
(最后确认)状态。
④客户端收到服务器的连接释放报文后,向服务端发出确认应答,进入TIME-WAIT
(时间等待)状态,此时TCP未释放掉,需要经过时间等待计时器设置的时间2MSL
(最大报文段生存时间)后,才进入CLOSED
状态。服务端只要收到了客户端发出的确认,立即进入CLOSED
状态;若没收到客户端发出的确认报文段,服务端会重传连接释放报文段。
TCP连接是双向的,在四次挥手中,前两次握手用于断开一个方向的连接,后两次握手用于断开另一方向的连接。
为什么客户端最后还要等待2MSL(最大报文生存时间)?
①为了保证服务端能收到客户端的确认应答。
若客户端发完确认应答后直接进入CLOSED
状态,那么如果该应答丢失,服务端等待超时后就会重新发送连接释放请求,但此时客户端已经关闭了,不会作出任何响应,因此服务端就无法正常关闭。
②防止已经失效的连接请求报文段出现在本连接中。
客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么是四次挥手?
因为当Server端收到Client端的SYN
连接请求报文后,不可以直接发送SYN+ACK
报文。因为数据发送的截止时间不同,只有等到Server端所有的报文都发送完了,这时Server端才能发送连接释放报文,之后两边才会真正的断开连接。故需要四次挥手。
TCP有哪些特点?
- TCP是面向连接的运输层协议。
- 点对点,每一条TCP连接只能有两个端点。
- TCP提供可靠交付的服务。
- TCP提供全双工通信。
- 面向字节流。
TCP和UDP的区别?
- TCP面向连接;UDP是无连接的,即发送数据之前不需要建立连接。
- TCP提供可靠的服务;UDP不保证可靠交付。
- TCP面向字节流,把数据看成一连串无结构的字节流;UDP是面向报文的。
- TCP有拥塞控制;UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如实时视频会议等)。
- 每一条TCP连接只能是点到点的;UDP支持一对一、一对多、多对一和多对多的通信方式。
- TCP首部开销20字节;UDP的首部开销小,只有8个字节。
TCP怎么保证传输过程的可靠性?
校验和:发送方在发送数据之前计算校验和,接收方收到数据后同样计算,如果不一致,那么传输有误。
确认应答,序列号:TCP进行传输时数据都进行了编号,每次接收方返回ACK都有确认序列号。
超时重传:如果发送方发送数据一段时间后没有收到ACK,那么就重发数据。
连接管理:三次握手和四次挥手的过程。
流量控制:TCP协议报头包含16位的窗口大小,接收方会在返回ACK时同时把自己的即时窗口填入,发送方就根据报文中窗口的大小控制发送速度。
拥塞控制:刚开始发送数据的时候,拥塞窗口是1,以后每次收到ACK,则拥塞窗口+1,然后将拥塞窗口和收到的窗口取较小值作为实际发送的窗口,如果发生超时重传,拥塞窗口重置为1。这样做的目的就是为了保证传输过程的高效性和可靠性。
TCP拥塞控制和流量控制都是什么,两者的区别?
流量控制是端到端的控制,例如A通过网络给B发数据,A发送的太快导致B没法接收(B缓冲窗口过小或者处理过慢),这时候的控制就是流量控制,原理是通过改变滑动窗口的大小来实现。
拥塞控制是A与B之间的网络发生堵塞导致传输过慢或者丢包,来不及传输。防止过多的数据注入到网络中,这样可以使网络中的路由器或链路不至于过载。拥塞控制是一个全局性的过程,涉及到所有的主机、路由器,以及与降低网络性能有关的所有因素。
HTTP协议的特点?
http协议是超文本传输协议。它是基于TCP协议的应用层传输协议,即客户端和服务端进行数据传输的 一种规则。该协议本身HTTP 是一种无状态的协议。
- HTTP允许传输任意类型的数据。传输的类型由Content-Type加以标记。
- 无状态。对于客户端每次发送的请求,服务器都认为是一个新的请求,上一次会话和下一次会话之间没有联系。
- 支持客户端/服务器模式。
HTTP报文格式
HTTP请求由请求行、请求头部、空行和请求体四个部分组成。
- 请求行:包括请求方法,访问的资源URL,使用的HTTP版本。
GET
和POST
是最常见的HTTP方法,除此以外还包括DELETE、HEAD、OPTIONS、PUT、TRACE
。 - 请求头:格式为“属性名:属性值”,服务端根据请求头获取客户端的信息,主要有
cookie、host、connection、accept-language、accept-encoding、user-agent
。 - 请求体:用户的请求数据如用户名,密码等。
HTTP响应也由四个部分组成,分别是:状态行、响应头、空行和响应体。
- 状态行:协议版本,状态码及状态描述。
- 响应头:响应头字段主要有
connection、content-type、content-encoding、content-length、set-cookie、Last-Modified,、Cache-Control、Expires
。 - 响应体:服务器返回给客户端的内容。
HTTP状态码有哪些?
HTTP1.0和HTTP1.1的区别?
- 长连接:HTTP1.0默认使用短连接,每次请求都需要建立新的TCP连接,连接不能复用。HTTP1.1支持长连接,复用TCP连接,允许客户端通过同一连接发送多个请求。不过,这个优化策略也存在问题,当一个队头的请求不能收到响应的资源时,它将会阻塞后面的请求。这就是“队头阻塞”问题。
- 断点续传:HTTP1.0 不支持断点续传。HTTP1.1 新增了 range 字段,用来指定数据字节位置,支持断点续传。
- 错误状态响应码:在HTTP1.1中新增了24个错误状态响应码,如
409(Conflict)
表示请求的资源与资源的当前状态发生冲突、410(Gone)
表示服务器上的某个资源被永久性的删除。 - Host头处理:在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址,因此,请求消息中的URL并没有传递主机名。到了HTTP1.1时代,虚拟主机技术发展迅速,在一台物理服务器上可以存在多个虚拟主机,并且它们共享一个IP地址,故HTTP1.1增加了HOST信息。
HTTP1.1和 HTTP2.0的区别?
HTTP2.0相比HTTP1.1支持的特性:
- 新的二进制格式:HTTP1.1 基于文本格式传输数据;HTTP2.0采用二进制格式传输数据,解析更高效。
- 多路复用:在一个连接里,允许同时发送多个请求或响应,并且这些请求或响应能够并行的传输而不被阻塞,避免 HTTP1.1 出现的”
队头堵塞
”问题。 - 头部压缩,HTTP1.1的header带有大量信息,而且每次都要重复发送;HTTP2.0 把header从数据中分离,并封装成头帧和数据帧,使用特定算法压缩头帧,有效减少头信息大小。并且HTTP2.0在客户端和服务器端记录了之前发送的键值对,对于相同的数据,不会重复发送。比如请求a发送了所有的头信息字段,请求b则只需要发送差异数据,这样可以减少冗余数据,降低开销。
- 服务端推送:HTTP2.0允许服务器向客户端推送资源,无需客户端发送请求到服务器获取。
HTTPS与HTTP的区别?
- HTTP是超文本传输协议,信息是明文传输;HTTPS则是具有安全性的ssl加密传输协议。
- HTTP和HTTPS用的端口不一样,HTTP端口是80,HTTPS是443。
- HTTPS协议需要到CA机构申请证书,一般需要一定的费用。
- HTTP运行在TCP协议之上;HTTPS运行在SSL协议之上,SSL运行在TCP协议之上。
HTTPS原理
-
客户端通过浏览器请求https网站,将支持的加密算法信息发给服务器。
-
服务器选择一套浏览器支持的加密算法,以证书的形式回发给客户端,包含颁发机构、网址、公钥、证书有效期等信息。
-
客户端(SSL/TLS)解析证书验证证书合法性,生成对称加密的密钥,该密钥称之为client key,即客户端密钥,用服务器的公钥对客户端密钥进行非对称加密,将加密之后的客户端对称密钥发送给服务器。
-
服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后的明文就是客户端密钥,然后用客户端密钥对数据进行对称加密,这样数据就变成了密文,再将加密后的密文发送给客户端。
-
客户端收到服务器发送来的密文,用客户端密钥对其进行对称解密,得到服务器发送的数据。整个HTTPS传输完成。
简述DNS协议
DNS协议是基于UDP
的应用层协议,它的功能是根据用户输入的域名,解析出该域名对应的IP地址,从而给客户端进行访问。
DNS 的解析过程?
- 浏览器搜索自己的DNS缓存
- 若没有,则搜索操作系统中的DNS缓存和hosts文件
- 若没有,则操作系统将域名发送至本地域名服务器,本地域名服务器查询自己的DNS缓存,查找成功则返回结果,否则依次向根域名服务器、顶级域名服务器、权限域名服务器发起查询请求,最终返回IP地址给本地域名服务器
- 本地域名服务器将得到的IP地址返回给操作系统,同时自己也将IP地址缓存起来
- 操作系统将 IP 地址返回给浏览器,同时自己也将IP地址缓存起来
- 浏览器得到域名对应的IP地址
浏览器中输入URL返回页面过程?
- 解析域名,找到主机 IP。
- 浏览器利用 IP 直接与网站主机通信,三次握手,建立 TCP 连接。浏览器会以一个随机端口向服务端的 web 程序 80 端口发起 TCP 的连接。
- 建立 TCP 连接后,浏览器向主机发起一个HTTP请求。
- 服务器响应请求,返回响应数据。
- 浏览器解析响应内容,进行渲染,呈现给用户。
简述cookie
HTTP 协议本身是无状态的,为了使其能处理更加复杂的逻辑,HTTP/1.1 引入 Cookie 来保存状态信息。
Cookie是由服务端产生的,再发送给客户端保存,当客户端再次访问的时候,服务器可根据cookie辨识客户端是哪个,以此可以做个性化推送,免账号密码登录等等。
简述session
session用于标记特定客户端信息,存在在服务器的一个文件里。 一般客户端带Cookie对服务器进行访问,可通过cookie中的session id从整个session中查询到服务器记录的关于客户端的信息。
Cookie和Session的区别?
- 作用范围不同,Cookie 保存在客户端,Session 保存在服务器端。
- 有效期不同,Cookie 可设置为长时间保持,比如我们经常使用的默认登录功能,Session 一般失效时间较短,客户端关闭或 Session 超时都会失效。
- 隐私策略不同,Cookie 存储在客户端,容易被窃取;Session 存储在服务端,安全性相对 Cookie 要好一些。
- 存储大小不同, 单个 Cookie 保存的数据不能超过 4K;对于 Session 来说存储没有上限,但出于对服务器的性能考虑,Session 内不要存放过多的数据,并且需要设置 Session 删除机制。
什么是对称加密和非对称加密?
对称加密:通信双方使用相同的密钥进行加密。特点是加密速度快,但是缺点是密钥泄露会导致密文数据被破解。常见的对称加密有AES
和DES
算法。
非对称加密:它需要生成两个密钥,公钥和私钥。公钥是公开的,任何人都可以获得,而私钥是私人保管的。公钥负责加密,私钥负责解密;或者私钥负责加密,公钥负责解密。这种加密算法安全性更高,但是计算量相比对称加密大很多,加密和解密都很慢。常见的非对称算法有RSA
和DSA
。
TCP的粘包问题怎么解决
- 粘包的概念
TCP是一个基于字节流的传输服务,"流"意味着TCP所传输的数据是没有边界的。这不同于UDP提供基于消息的传输服务,其传输的数据是有边界的。TCP的发送方无法保证对等方每次接收到的是一个完整的数据包。
- 粘包的原因
-
发送端原因:由于TCP协议本身的机制(面向连接的可靠协议-三次握手机制)客户端与服务器会维持一个连接,数据在连接不断开的情况下,可以持续不断地将多个数据包发往服务器,但是如果发送的网络数据包太小,那么他本身会启用Nagle算法(可配置是否启用)对较小的数据包进行合并(基于此,TCP的网络延迟要UDP的高些)然后再发送(超时或者包大小足够)。因此,服务器在接收到消息(数据流)的时候就无法区分哪些数据包是客户端自己分开发送的,这样产生了粘包。
-
接收端原因:服务器在接收到数据后,放到缓冲区中,如果消息没有被及时从缓存区取走,下次在取数据的时候可能就会出现一次取出多个数据包的情况,造成粘包现象。
- 解决办法
①对于发送方引起的粘包现象,用户可通过编程设置来避免,TCP提供了强制数据立即传送的操作指令push,TCP软件收到该操作指令后,就立即将本段数据发送出去,而不必等待发送缓冲区满。
②对于接收方引起的粘包现象,则可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施,使其及时接收数据,从而尽量避免出现粘包现象。
③在每次使用TCP协议发送数据流时,在开头标记一个数据流长度信息,并固定该报文长度。在接收数据时先接收该长度字节数据,判断发送方发送的数据流长度,并只接收该长度字节数据,就可以实现拆包,完美解决tcp粘包问题。
Get与Post区别
-
Get:指定资源请求数据,刷新无害,Get请求的数据会附加到url中,传输数据的大小受到url的限制。
-
Post:向指定资源提交要被处理的数据。刷新会使数据会被重复提交。Post在发送数据前会先将请求头发送给服务器进行确认,然后才真正发送数据。