TCP/IP
模型看作是 OSI
七层模型的精简版本,由以下 4 层组成:
应用层位于传输层之上,主要提供两个终端设备上的应用程序之间信息交换的服务,它定义了信息交换的格式,消息会交给下一层传输层来传输。 我们把应用层交互的数据单元称为报文。
负责向两台终端设备进程之间的通信提供通用的数据传输服务。
应用进程利用该服务传送应用层报文。
“通用的”是指并不针对某一个特定的网络应用,而是多种应用可以使用同一个运输层服务。
运输层主要使用以下两种协议:
① 负责为分组交换网上的不同主机提供通信服务。
② 网络层的还有一个任务就是选择合适的路由,使源主机运输层所传下来的分株,能通过网络层中的路由器找到目的主机。
在发送数据时,网络层把运输层产生的报文段或用户数据报封装成分组和包进行传送。
在 TCP/IP
体系结构中,由于网络层使用 IP
协议,因此分组也叫 IP
数据报,简称数据报。
互联网是由大量的异构(heterogeneous)网络通过路由器(router)相互连接起来的。互联网使用的网络层协议是无连接的网际协议(Intert Prococol)和许多路由选择协议,因此互联网的网络层也叫做网际层或IP 层。
HTTP 协议,全称超文本传输协议(Hypertext Transfer Protocol)。HTTP 协议就是用来规范超文本(网络上各种消息)的传输,规范浏览器和服务器端的行为的。
HTTP 是一个无状态(stateless)协议,也就是说服务器不维护任何有关客户端过去所发请求的消息。这其实是一种懒政,有状态协议会更加复杂,需要维护状态(历史信息),而且如果客户或服务器失效,会产生状态的不一致,解决这种不一致的代价更高。
HTTP
是应用层协议,它以 TCP
(传输层)作为底层协议,默认端口为 80. 通信过程主要如下:
TCP
连接(创建套接字 Socket)。TCP
连接。HTTP
客户端)与 Web
服务器(HTTP
服务器)交换 HTTP
消息。TCP
连接。HTTPS
协议(Hyper Text Transfer Protocol Secure
),是 HTTP
的加强安全版本。HTTPS
是基于 HTTP
的,也是用 TCP
作为底层协议,并额外使用 SSL/TLS
协议用作加密和安全认证。默认端口号是 443
HTTPS
协议中,SSL
通道通常使用基于密钥的加密算法,密钥长度通常是 40 比特或 128 比特。
结合了 SSL/TLS 和 TCP 协议,对通信数据进行加密,解决了 HTTP 数据透明的问题。
没有太大的区别。SSL
指安全套接字协议(Secure Sockets Layer),始发1996年,1999 年SSL 3.0 进一步升级,新版本被命名为 TLS
1.0。通常把 HTTPS
中的核心加密协议混成为 SSL/TLS
。
SSL/TLS 的核心要素是非对称加密。非对称加密采用两个密钥——一个公钥(加密者),一个私钥(解密者)。在通信时,私钥仅由解密者保存,公钥由任何一个想与解密者通信的发送者(加密者)所知。
非对称加密:公钥和私钥需要采用一种复杂的数学机制生成。公私钥对的生成算法依赖于单向陷门函数。(计算的代价较高,效率太低)
对称加密:通信双方共享唯一密钥 k,加解密算法已知,加密方利用密钥 k 加密,解密方利用密钥 k 解密,保密性依赖于密钥 k 的保密性。
使用非对称加密,对对称加密的密钥进行加密,保护该密钥不在网络信道中被窃听。这样通信双方只需要一次非对称加密,交换对称加密的密钥,在之后的信息通信中,使用绝对安全的密钥,对信息进行对称加密,即可保证传输消息的保密性。
当客户端(浏览器)向服务器发送 HTTPS
请求时,一定要先获取目标服务器的证书,并根据证书上的信息,检验证书的合法性。一旦客户端检测到证书非法,就会发生错误。客户端获取了服务器的证书后,由于证书的信任性是由第三方信赖机构认证的,而证书上又包含着服务器的公钥信息,客户端就可以放心的信任证书上的公钥就是目标服务器的公钥。
HTTP/1.0
仅定义了16种状态码。HTTP/1.1
中大量状态码,错误响应状态码就新增24种。
100 (Continue)
——在请求大资源前的预热请求,
206 (Partial Content)
——范围请求的标识码,
409 (Conflict)
——请求与当前资源的规定冲突,
410 (Gone)
——资源已被永久转移,而且没有任何已知的转发地址。
缓存技术通过避免用户与源服务器的频繁交互,节约了大量的网络带宽,降低了用户接收信息的延迟。
Expires
标签:标志(时间)一个响应体,在 Expires
标志时间内的请求,都会获得该响应体缓存。Last-Modified
:标记了被请求资源在服务器端的最后一次修改。If-Modified-Since
:标志一个时间,意为客户端向服务器进行问询是否修改。If-Modified-Since
时间后,资源确实没有修改过,则返回给客户端一个 304 not modified
响应头,表示”缓冲可用,你从浏览器里拿吧!”。If-Modified-Since
时间后,资源被修改过,则返回给客户端一个 200 OK
的响应体,并附带全新的资源内容,表示”你要的我已经改过的,给你一份新的”。HTTP/1.0
的基础上,大大增加了灵活性和扩展性。基本工作原理和 HTTP/1.0
保持不变,而是增加了更多细致的特性。其中,请求头中最常见的特性就是 Cache-Control
。HTTP/1.0
默认使用短连接,也就是说,客户端和服务器每进行一次 HTTP
操作,就建立一次连接,任务结束就中断连接。
当客户端浏览器访问的某个 HTML
或其他类型的 Web
页中包含有其他的 Web
资源,每遇到这样一个 Web
资源,浏览器就会重新建立一个TCP连接,这样就会导致有大量的**“握手报文”和“挥手报文”**占用了带宽。
HTTP/1.1 优化为默认长连接模式。采用长连接模式的请求报文会通知服务端:“我向你请求连接,并且连接成功建立后,请不要关闭”。因此,该TCP连接将持续打开,为后续的客户端-服务端的数据交互服务。也就是说在使用长连接的情况下,当一个网页打开完成后,客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭,客户端再次访问这个服务器时,会继续使用这一条已经建立的连接。
如果 TCP 连接一直保持的话也是对资源的浪费,因此,一些服务器软件(如 Apache)还会支持超时时间的时间。在超时时间之内没有新的请求达到,TCP 连接才会被关闭。
(有必要说明的是,HTTP/1.0
仍提供了长连接选项,即在请求头中加入Connection: Keep-alive
。同样的,在 HTTP/1.1
中,如果不希望使用长连接选项,也可以在请求头中加入 Connection: close
,这样会通知服务器端:“我不需要长连接,连接成功后即可关闭”。)
* HTTP 协议的长连接和短连接,实质上是 TCP 协议的长连接和短连接。
* 实现长连接需要客户端和服务端都支持长连接。
域名系统(DNS)允许多个主机名绑定到同一个IP
地址上,但是HTTP/1.0
并没有考虑这个问题,假设我们有一个资源URL是 http://example1.org/home.html
,HTTP/1.0
的请求报文中,将会请求的是GET /home.html HTTP/1.0
.也就是不会加入主机名。这样的报文送到服务器端,服务器是理解不了客户端想请求的真正网址。
因此,HTTP/1.1
在请求头中加入了 Host
字段。加入 Host
字段的报文头部将会是:
GET /home.html HTTP/1.1
Host: example1.org
这样,服务器端就可以确定客户端想要请求的真正的网址了。
HTTP/1.1
引入了范围请求(range request)机制,以避免带宽的浪费。当客户端想请求一个文件的一部分,或者需要继续下载一个已经下载了部分但被终止的文件,HTTP/1.1
可以在请求中加入 Range
头部,以请求(并只能请求字节型数据)数据的一部分。服务器端可以忽略 Range
头部,也可以返回若干 Range
响应。
如果一个响应包含部分数据的话,那么将带有 206 (Partial Content)
状态码。该状态码的意义在于避免了 HTTP/1.0
代理缓存错误地把该响应认为是一个完整的数据响应,从而把他当作为一个请求的响应缓存。
在范围响应中,Content-Range
头部标志指示出了该数据块的偏移量和数据块的长度。
使用场景为,存在某些较大的文件请求,服务器可能不愿意响应这种请求,此时状态码100
可以作为指示请求是否会被正常响应
然而在 HTTP/1.0
中,并没有 100
(Continue)状态码,要想触发这一机制,可以发送一个 Expect
头部,其中包含一个 100-continue
的值。
许多格式的数据在传输时都会做预压缩处理。数据的压缩可以大幅优化带宽的利用。然而,HTTP/1.0
对数据压缩的选项提供的不多,不支持压缩细节的选择,也无法区分端到端(end-to-end)压缩或者是逐跳(hop-by-hop)压缩。
HTTP/1.1
则对内容编码(content-codings,端到端)和传输编码(transfer-codings,逐跳)做了区分。
HTTP/1.0
包含了 Content-Encoding
头部,对消息进行端到端编码。HTTP/1.1
加入了Transfer-Encoding
头部,可以对消息进行逐跳传输编码。HTTP/1.1
还加入了Accept-Encoding
头部,是客户端用来指示他能处理什么样的内容编码。
HTTP1.0
中主要使用 header
里的 If-Modified-Since,Expires
来做为缓存判断的标准,HTTP1.1
则引入了更多的缓存控制策略例如 Entity tag
,If-Unmodified-Since
, If-Match
, If-None-Match
等更多可供选择的缓存头来控制缓存策略。HTTP1.0
中,存在一些浪费带宽的现象,例如客户端只是需要某个对象的一部分,而服务器却将整个对象送过来了,并且不支持断点续传功能,HTTP1.1
则在请求头引入了 range
头域,它允许只请求资源的某个部分,即返回码是 206(Partial Content)
,这样就方便了开发者自由的选择以便于充分利用带宽和连接。HTTP/1.1
在请求头中加入了 Host
字段。Web 浏览器与 Web 服务器之间的通信而设计的。浏览器浏览网页就是通过 HTTP 请求进行加载。
HTTP
协议是基于 TCP协议,发送 HTTP
请求之前首先要建立 TCP
连接也就是要经历 3 次握手。目前使用的 HTTP
协议大部分都是 1.1
。在 1.1
的协议里面,默认是开启了 Keep-Alive
的,这样的话建立的连接就可以在多次请求中被复用了。
HTTP
协议是**“无状态”的协议**,它无法记录客户端用户的状态,一般我们都是通过 Session
来记录客户端用户的状态。
基于 TCP 协议,用来发送电子邮件。
SMTP
协议,我将我写好的邮件交给163邮箱服务器(邮局)。SMTP
协议来检测:SMTP
协议只负责邮件的发送,真正负责接收的协议是 POP3/IMAP
。(IMAP
协议更新,功能更多)
功能:提供文件传输服务,基于 TCP 实现可靠的传输。
好处:可以屏蔽操作系统和文件存储方式。
FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点:就在于它在两台通信的主机之间使用了两条 TCP 连接(其它客户服务器应用程序一般只有一条 TCP 连接):
Telnet
协议 通过一个终端登陆到其他服务器,建立在可靠的传输协议 TCP 之上。Telnet
协议的最大缺点之一是所有数据(包括用户名和密码)均以明文形式发送,这有潜在的安全风险。这就是为什么如今很少使用Telnet
并被一种称为 SSH
的非常安全的协议所取代的主要原因。
Telnet
和 SSH
之间的主要区别在于 SSH
协议会对传输的数据进行加密保证数据安全性。
为了准确无误地把数据送达目标处,TCP 协议采用了三次握手策略。
建立可靠的通信信道,说到通讯,简单来说就是数据的发送与接收,而三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
ACK
(确认信号) 是为了告诉客户端,我接收到的信息确实就是你所发送的信号了,这表明从客户端到服务端的通信是正常的。
而回传 SYN
(建立联机信号) 则是为了建立并确认从服务端到客户端的通信。”
FIN
,用来关闭客户端到服务器的数据传送FIN
,它发回一 个 ACK
,确认序号为收到的序号加 1 。和 SYN
一样,一个 FIN 将占用一个序号FIN
给客户端ACK
报文确认,并将确认序号设置为收到序号加 1任何一方都可以在数据传送结束后发出连接释放的通知,待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候,则发出连接释放通知,对方确认后就完全关闭了 TCP
连接。
(举个例子:A 和 B 打电话,通话即将结束后,A 说“我没啥要说的了”,B 回答“我知道了”,但是 B 可能还会有要说的话,A 不能要求 B 跟着自己的节奏结束通话,于是 B 可能又巴拉巴拉说了一通,最后 B 说“我说完了”,A 回答“知道了”,这样通话才算结束。)
UDP
在传送数据之前不需要先建立连接,远地主机在收到 UDP
报文后,不需要给出任何确认。虽然 UDP
不提供可靠交付,但在某些情况下 UDP
却是一种最有效的工作方式(一般用于即时通信),比如: QQ 语音、 QQ 视频 、直播等等
TCP
提供面向连接的服务。在传送数据之前必须先建立连接,数据传送结束后要释放连接。 TCP
不提供广播或多播服务。由于 TCP
要提供可靠的,面向连接的传输服务(TCP
的可靠体现在 TCP
在传递数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完后,还会断开连接用来节约系统资源),这难以避免增加了许多开销,如确认,流量控制,计时器以及连接管理等。这不仅使协议数据单元的首部增大很多,还要占用许多处理机资源。TCP
一般用于文件传输、发送和接收邮件、远程登录等场景。
OSI 模型中数据链路层和传输层的错误纠正协议之一。
它通过使用确认和超时这两个机制,在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧,它通常会重新发送。
ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。
停止等待 ARQ 协议 :为了实现可靠传输的,它的基本原理就是每发完一个分组就停止发送,等待对方确认(回复 ACK)。如果过了一段时间(超时时间后),还是没有收到 ACK 确认,说明没有发送成功,需要重新发送,直到收到确认后再发下一个分组。
在停止等待协议中,若接收方收到重复分组,就丢弃该分组,但同时还要发送确认。
优点: 简单。缺点: 信道利用率低,等待时间长
连续 ARQ 协议:可提高信道利用率。**发送方维持一个发送窗口,凡位于发送窗口内的分组可以连续发送出去,而不需要等待对方确认。**接收方一般采用累积确认,对按序到达的最后一个分组发送确认,表明到这个分组为止的所有分组都已经正确收到了。
优缺点:
优点: 信道利用率高,容易实现,即使确认丢失,也不必重传。
缺点: 不能向发送方反映出接收方已经正确收到的所有分组的信息。 比如:发送方发送了 5 条 消息,中间第三条丢失(3 号),这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落,而只好把后三个全部重传一次。这也叫 Go-Back-N(回退 N),表示需要退回来重传已经发送过的 N 个消息。
TCP
利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率,保证接收方来得及接收。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小,从而影响发送方的发送速率。将窗口字段设置为 0,则发送方不能发送数据。
拥塞:在某段时间,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏。
拥塞控制:防止过多的数据注入到网络中,这样就可以使网络中的路由器或链路不致过载。
前提:网络能够承受现有的网络负荷。
拥塞控制是一个全局性的过程,涉及到所有的主机,所有的路由器,以及与降低网络传输性能有关的所有因素。
流量控制往往是点对点通信量的控制,是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率,以便使接收端来得及接收。
为了进行拥塞控制,TCP
发送方要维持一个 拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度,并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的一个。
TCP
的拥塞控制采用了四种算法,即 慢开始(由小到大逐渐增大发送窗口) 、 拥塞避免 (拥塞窗口 cwnd 缓慢增大)、快重传与快恢复(如果接收机接收到一个不按顺序的数据段,它会立即给发送机发送一个重复确认)。在网络层也可以使路由器采用适当的分组丢弃策略(如主动队列管理 AQM),以减少网络拥塞的发生。
HTTP
是一种不保存状态,即无状态(stateless)协议。也就是说 HTTP
协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢?Session 机制的存在就是为了解决这个问题,**Session
的主要作用就是通过服务端记录用户的状态。**典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP
协议是无状态的。服务端给特定的用户创建特定的 Session
之后就可以标识这个用户并且跟踪这个用户了(一般情况下,服务器会在一定时间内保存这个 Session
,过了时间限制,就会销毁这个 Session
)。
在服务端保存 Session
的方法很多,最常用的就是内存和数据库(比如是使用内存数据库 redis
保存)。既然 Session
存放在服务器端,那么我们如何实现 Session
跟踪呢?大部分情况下,我们都是通过在 Cookie
中附加一个 Session ID
来方式来跟踪。
Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在 URL 路径的后面。
Cookie
和 Session
都是用来跟踪浏览器用户身份的会话方式,但是两者的应用场景不太一样。
Cookie
一般用来保存用户信息 比如 ① 我们在 Cookie
中保存已经登录过的用户信息,下次访问网站的时候页面可以自动帮你把登录的一些基本信息给填了;② 一般的网站都会有保持登录,也就是说下次你再访问网站的时候就不需要重新登录了,这是因为用户登录的时候我们可以存放了一个 Token
在 Cookie
中,下次登录的时候只需要根据 Token
值来查找用户即可(为了安全考虑,重新登录一般要将 Token 重写);③ 登录一次网站后访问网站其他页面不需要重新登录。
Session
的主要作用就是通过服务端记录用户的状态。 典型的场景是购物车,当你要添加商品到购物车的时候,系统不知道是哪个用户操作的,因为 HTTP
协议是无状态的。服务端给特定的用户创建特定的 Session
之后就可以标识这个用户并且跟踪这个用户了。
Cookie
数据保存在客户端(浏览器端),Session
数据保存在服务器端。
Cookie
存储在客户端中,而 Session
存储在服务器上,相对来说 Session
安全性更高。如果要在 Cookie
中存储一些敏感信息,不要直接写入 Cookie
中,最好能将 Cookie
信息加密,然后使用到的时候再去服务器端解密。
URI
(Uniform Resource Identifier) 是统一资源标志符,可以唯一标识一个资源。URL
(Uniform Resource Locator) 是统一资源定位符,可以提供该资源的路径。它是一种具体的 URI
,即 URL
可以用来标识一个资源,而且还指明了如何 locate 这个资源。URI
的作用像身份证号一样,URL
的作用更像家庭住址一样。URL
是一种具体的 URI
,它不仅唯一标识资源,而且还提供了定位该资源的信息。本文档为个人方便自己熟记而整理,来自javaguide。
javaguide是个优秀的计算机知识整理:https://javaguide.cn/