七层模型,亦称OSI(Open System Interconnection),它是一个七层的、抽象的模型体,不仅包括一系列抽象的术语或概念,也包括具体的协议。
OSI 七层从上往下依次是:应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
图片来源于网络
TCP/IP 四层从上往下依次是:应用层、传输层、网络层(互联网层)、链路层(数据链路层/网络接口层)。与 OSI 七层的映射关系如下:
OSI七层和TCP/IP的区别:
附一张经典图:
图片来源于网络
小结 TCP 与 UDP 的区别:
一句话:通过校验和、序列号、确认应答、超时重传、连接管理、流量控制、拥塞控制等机制来保证可靠性。
(1)校验和
在数据传输过程中,将发送的数据段都当做一个16位的整数,将这些整数加起来,并且前面的进位不能丢弃,补在最后,然后取反,得到校验和。
发送方:在发送数据之前计算校验和,并进行校验和的填充。接收方:收到数据后,对数据以同样的方式进行计算,求出校验和,与发送方进行比较。
(2)序列号
TCP 传输时将每个字节的数据都进行了编号,这就是序列号。序列号的作用不仅仅是应答作用,有了序列号能够将接收到的数据根据序列号进行排序,并且去掉重复的数据。
(3)ACK 确认应答
当消息接收方接收到消息,返回一个对应的 ACK,发送方就知道这个消息已经处理完成,这个 ACK 报文中带有对应的确认序列号,告诉发送方,接收了哪些数据,下一次数据从哪里传。
(4)超时重传
消息超时也就是说没有在等待时间内收到对方的 ACK 消息。这个时候,为了保证消息对方能够正确收到,我们需要将这个消息进行重新传输,如果尝试成功,则继续发送接下来的包。若尝试几次均失败,那么 TCP 会强行断开连接,发送 RST 信息。并告知应用程序连接错误。
(5)连接可靠
三次握手、四次挥手的过程。
(6)流量控制
如果发送方的发送速度太快,会导致接收方的接收缓冲区填充满了,这时候继续传输数据,就会造成大量丢包,进而引起丢包重传等等一系列问题。TCP 支持根据接收端的处理能力来决定发送端的发送速度,这就是流量控制机制。
具体实现方式:接收端将自己的接收缓冲区大小放入 TCP 首部的『窗口大小』字段中,通过 ACK 通知发送端。
(7)拥塞控制
TCP 传输过程中一开始就发送大量数据,如果当时网络非常拥堵,可能会造成拥堵加剧。所以 TCP 引入了慢启动机制,在开始发送数据的时候,先发少量的数据探探路。
TCP 会将较大数据拆分成一个个小的数据包再进行发送。发送完一个包,等待 ACK,这种模式是最简单的。但是问题也很明显,慢,吞吐量低。所以我们在等待 ACK 的同时,可以继续发送接下来的包。也就是说,滑动窗口就是在发送完一个数据包后,不需要等待 ACK 消息返回,可以发送后面的数据包,解决吞吐量问题。
发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小,发送方根据这个值和其它信息设置自己的窗口大小。
发送方的发送缓存内的数据都可以被分为4类:
其中类型2和3都属于发送窗口。
接收方的缓存数据分为3类:
其中类型2属于接收窗口。
TCP header中有一个Window Size字段,它其实是指接收端的窗口,即接收窗口。用来告知发送端自己所能接收的数据量,从而达到一部分流控的目的。
发送窗口只有收到发送窗口内字节的ACK确认,才会移动发送窗口的左边界。
接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下,窗口不会移动,并不对后续字节确认。以此确保发送端会对这些数据重传。
遵循快速重传、累计确认、选择确认等规则。
防止发送方发地太快,使得网络来不及处理,从而导致网络拥塞。
❝如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。 ❞
拥塞控制的方法主要有以下四种:
快重传示意图
慢开始和快恢复的快慢指的是 cwnd 的设定值,而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1,而快恢复 cwnd 设定为 ssthresh。
TCP报文段
❝字段解释:
❞
有了上面的铺垫,再来看下面这图就容易明白了吧?
不行。TCP进行可靠传输的关键就在于维护一个序列号,三次握手的过程即是通信双方相互告知序列号起始值, 并确认对方已经收到了序列号起始值。
如果只是两次握手,至多只有客户端的起始序列号能被确认,服务器端的序列号则得不到确认。
MSL即报文最大生存时间。设置2MSL可以保证上一次连接的报文已经在网络中消失,不会出现与新TCP连接报文冲突的情况。
主要原因是当服务端收到客户端的 FIN 数据包后,服务端可能还有数据没发完,不会立即close。
所以服务端会先将 ACK 发过去告诉客户端我收到你的断开请求了,但请再给我一点时间,这段时间用来发送剩下的数据报文,发完之后再将 FIN 包发给客户端表示现在可以断了。之后客户端需要收到 FIN 包后发送 ACK 确认断开信息给服务端。
第三次是可以携带数据的。
假如第一次握手可以携带数据的话,如果恶意攻击服务器,每次都在第一次握手中的SYN报文中放入大量数据。而且频繁重复发SYN报文,服务器会花费很多的时间和内存空间去接收这些报文。
第三次握手,此时客户端已经处于ESTABLISHED状态。对于客户端来说,他已经建立起连接了,并且已经知道服务器的接收和发送能力是正常的。所以也就可以携带数据了。
❝第三次的ACK在网络中丢失,那么服务端该TCP连接的状态为SYN_RECV,并且会根据 TCP的超时重传机制,会等待3秒、6秒、12秒后重新发送SYN+ACK包,以便客户端重新发送ACK包。如果重发指定次数之后,仍然未收到 客户端的ACK应答,那么一段时间后,服务端自动关闭这个连接。 ❞
❝客户端认为这个连接已经建立,如果客户端向服务端发送数据,服务端将以RST包(Reset,复位,用于异常的关闭连接)响应。此时,客户端知道第三次握手失败。 ❞
服务端收到客户端发出的 SYN 请求后,会把这个连接信息存储到半链接队列(SYN 队列)。
服务端收到第三次握⼿的 ACK 后,内核会把连接从半连接队列移除,然后创建新的完全的连接,并将其添加到全连接队列(accept 队列),等待进程调⽤ accept 函数时把连接取出来。
这两个队列都是有大小限制的,当超过容量后就会将链接丢弃,或者返回 RST 包。
TCP 发送数据时会根据 TCP 缓冲区的实际情况进行包的划分,一个完整的包可能会被 TCP 拆分成多个包进行发送,也有可能把多个小的包封装成一个大的数据包发送,这就是 TCP 粘包和拆包问题。
发生 TCP 粘包的原因:
发生 TCP 拆包的原因:
解决方案:
DNS协议是基于UDP的应用层协议,它的功能是根据用户输入的域名,解析出该域名对应的IP地址,从而给客户端进行访问。
域名解析 -> 建立TCP连接(三次握手)-> 发起http请求 -> 服务器响应http请求,浏览器得到html代码 -> 浏览器解析html代码,并请求html代码中的资源(如 js、css、图片等)-> 浏览器对页面进行渲染呈现给用户。
先说一下 IP 的基本特点:
IP地址由四段组成,每个字段是一个字节,8位,最大值是255。IP地址由两部分组成,即网络地址和主机地址。网络地址表示其属于互联网的哪一个网络,主机地址表示其属于该网络中的哪一台主机。
IP 地址主要分为A、B、C三类及特殊地址D、E这五类:
端口 | 服务 |
---|---|
21 | FTP(文件传输协议) |
22 | SSH(安全外壳协议) |
23 | Telnet(internet远程登录服务的标准协议 |
25 | SMTP简单邮件传输服务 |
53 | DNS(域名系统服务) |
80 | HTTP(超文本传输协议) |
http协议是超文本传输协议。它是基于TCP协议的应用层传输协议,即客户端和服务端进行数据传输的一种规则。该协议本身HTTP 是一种无状态的协议。
常见错误码:
+ 200 (成功) 服务器已成功处理了请求。通常,这表示服务器提供了请求的网页。
+ 201 (已创建) 请求成功并且服务器创建了新的资源。
+ 202 (已接受) 服务器已接受请求,但尚未处理。
+ 203 (非授权信息) 服务器已成功处理了请求,但返回的信息可能来自另一来源。
+ 204 (无内容) 服务器成功处理了请求,但没有返回任何内容。
+ 205 (重置内容) 服务器成功处理了请求,但没有返回任何内容。
+ 206 (部分内容) 服务器成功处理了部分 GET 请求。
+ 301 永久重定向
+ 302 临时重定向
+ 304 资源没修改,用之前缓存就行
+ 400 客户端请求的报文有错误
+ 401 (未授权) 请求要求身份验证。 对于需要登录的网页,服务器可能返回此响应。
+ 403 (禁止) 服务器拒绝请求。
+ 404 表示请求的资源在服务器上不存在或未找到
+ 500 (服务器内部错误) 服务器遇到错误,无法完成请求。
+ 501 (尚未实施) 服务器不具备完成请求的功能。例如,服务器无法识别请求方法时可能会返回此代码。
+ 502 (错误网关) 服务器作为网关或代理,从上游服务器收到无效响应。
+ 503 (服务不可用) 服务器目前无法使用(由于超载或停机维护)。通常,这只是暂时状态。
+ 504 (网关超时) 服务器作为网关或代理,但是没有及时从上游服务器收到请求。
+ 505 (HTTP 版本不受支持) 服务器不支持请求中所用的 HTTP 协议版本。
转发是服务器行为。服务器直接向目标地址访问 URL,将相应内容读取之后发给浏览器,用户浏览器地址栏 URL不变,转发页面和转发到的页面可以共享 request 里面的数据。
重定向是利用服务器返回的状态码来实现的,如果服务器返回 301 或者 302,浏览器收到新的消息后自动跳转到新的网址重新请求资源。用户的地址栏 URL 会发生改变,而且不能共享数据。
请求头:
Accept: text/html,image/*( 浏览器可以接收的类型)
Accept-Charset: ISO-8859-1(浏览器可以接收的编码类型)
Accept-Encoding: gzip,compress(浏览器可以接收压缩编码类型)
Accept-Language: en-us,zh-cn(浏览器可以接收的语言和国家类型)
Host: www.it315.org:80(浏览器请求的主机和端口)
If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT(某个页面缓存时间)
Referer: http://www.it315.org/index. jsp(请求来自于哪个页面)
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)(浏览器相关信息)
Cookie:(浏览器暂存服务器发送的信息)
Connection: close(1.0)/Keep-Alive(1.1)(HTTP请求的版本的特点)
Date: Tue, 11 Jul 2000 18:23:51 GMT(请求网站的时间)
响应头:
Location: http://www.wekenw.com (控制浏览器显示哪个页面)
Server:apache tomcat(服务器的类型)
Content-Encoding: gzip(服务器发送的压缩编码方式)
Content-Length: 80(服务器发送显示的字节码长度)
Content-Language: zh-cn(服务器发送内容的语言和国家名)
Content-Type: image/jpeg; charset=UTF-8(服务器发送内容的类型和编码类型)
Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT(服务器最后一次修改的时间)
Refresh: 1;url=http://www.it315.org(控制浏览器1秒钟后转发URL所指向的页面)
Content-Disposition: attachment; filename=aaa.jpg(服务器控制浏览器发下载方式打开文件)
Transfer-Encoding: chunked(服务器分块传递数据到客户端)
Set-Cookie:SS=Q0=5Lb_nQ; path=/search(服务器发送Cookie相关的信息)
Expires: -1(服务器控制浏览器不要缓存网页,默认是缓存)
Cache-Control: no-cache(服务器控制浏览器不要缓存网页)
Pragma: no-cache(服务器控制浏览器不要缓存网页)
Connection: close/Keep-Alive(HTTP请求的版本的特点)
Date: Tue, 11 Jul 2000 18:23:51 GMT(响应网站的时间)
规定了请求头和请求尾,响应头和响应尾(get post)
每一个请求都是一个单独的连接,做不到连接的复用
HTTP1.1默认开启长连接,在一个TCP连接上可以传送多个HTTP请求和响应。使用 TCP 长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
支持管道(pipeline)网络传输,只要第一个请求发出去了,不必等其回来,就可以发第二个请求出去,可以减少整体的响应时间。
服务端无法主动push
HTTP中的长连接短连接指HTTP底层TCP的连接。
短连接:客户端与服务器进行一次HTTP连接操作,就进行一次TCP连接,连接结束TCP关闭连接。
长连接:如果HTTP头部带有参数keep-alive,即开启长连接网页完成打开后,底层用于传输数据的TCP连接不会直接关闭,会根据服务器设置的保持时间保持连接,保持时间过后连接关闭。
提出多路复用。多路复用前,文件是串行传输的,请求a文件,b文件只能等待,并且连接数过多。引入多路复用,a文件b文件可以同时传输。
引入了二进制数据帧。其中帧对数据进行顺序标识,有了序列id,服务器就可以进行并行传输数据。
http所有传输的内容都是明文,并且客户端和服务器端都无法验证对方的身份。https具有安全性的ssl加密传输协议,加密采用对称加密, https协议需要到ca申请证书,一般免费证书很少,需要交费。
SSL全称为Secure Sockets Layer即安全套接层,其继任为TLSTransport Layer Security传输层安全协议,均用于在传输层为数据通讯提供安全支持。
可以将HTTPS协议简单理解为HTTP协议+TLS/SSL
浏览器将支持的加密算法信息发给服务器
服务器选择一套浏览器支持的加密算法,以证书的形式回发给浏览器
客户端(SSL/TLS)解析证书验证证书合法性,生成对称加密的密钥,我们将该密钥称之为client key,即客户端密钥,用服务器的公钥对客户端密钥进行非对称加密。
客户端会发起HTTPS中的第二个HTTP请求,将加密之后的客户端对称密钥发送给服务器
服务器接收到客户端发来的密文之后,会用自己的私钥对其进行非对称解密,解密之后的明文就是客户端密钥,然后用客户端密钥对数据进行对称加密,这样数据就变成了密文。
服务器将加密后的密文发送给客户端
客户端收到服务器发送来的密文,用客户端密钥对其进行对称解密,得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束,整个HTTPS传输完成
XSS 即(Cross Site Scripting)中文名称为:跨站脚本攻击。XSS的重点不在于跨站点,而在于脚本的执行。
XSS的原理是:
恶意攻击者在web页面中会插入一些恶意的script代码。当用户浏览该页面的时候,那么嵌入到web页面中script代码会执行,因此会达到恶意攻击用户的目的。
XSS攻击最主要有如下分类:反射型、存储型、及 DOM-based型。反射性和DOM-baseed型可以归类为非持久性XSS攻击。存储型可以归类为持久性XSS攻击。
CSRF(Cross Site Request Forgery,跨站域请求伪造)是一种网络的攻击方式,它在 2007 年曾被列为互联网 20 大安全隐患之一,也被称为『One Click Attack』或者 『Session Riding』,通常缩写为CSRF或者XSRF,是一种对网站的恶意利用。
听起来像跨站脚本(XSS),但它与XSS非常不同,并且攻击方式几乎相左。
XSS利用站点内的信任用户,而CSRF则通过伪装来自受信任用户的请求来利用受信任的网站。与XSS攻击相比,CSRF攻击往往不大流行(因此对其进行防范的资源也相当稀少)和难以防范,所以被认为比XSS更具危险性。
❝由于非对称加密的方式不需要发送用来解密的私钥,所以可以保证安全性;但是和对称加密比起来,它非常的慢,所以我们还是要用对称加密来传送消息,但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。 ❞
数字签名必须保证实现以下三点功能:
该图只是进行了数字签名并没有对报文进行加密。
数字签名过程:A用私钥SKA对明文X进行D运算签名成为密文DSKA,B用A的公钥PKA对密文DSKA进行E运算还原出明文X。
❝那么这个过程是如何满足报文鉴别、报文的完整性、不可否认三个特点的呢?
❞