有关计算机网络基础的一些知识
1 HTTP
HTTP的缺点?
1.通信使用明文(不加密),内容可能会被窃听
HTTP 报文使用明文(指未经过加密的报文)方式发送。
2.不验证通信方的身份,因此有可能遭遇伪装
HTTP 协议中的请求和响应不会对通信方进行确认 , 任何人都可发起请求。
无法确定请求发送至目标的 Web 服务器是否是按真实意 图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
无法确定响应返回到的客户端是否是按真实意图接收响 应的那个客户端。有可能是已伪装的客户端。
无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息,只想发给特定用户通信的权限。
3.无法证明报文的完整性,所以有可能已遭篡改
所谓完整性是指信息的准确度。若无法证明其完整性,通常也就意味 着无法判断信息是否准确。 在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉。
1.1 序号、确认号等
序号(sequence number):seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。在一个TCP连接中传送的字节流中的每一个字节都按顺序编号。整个要传送的字节流的起始序号必须在连接建立时设置。首部中的序号字段则指的是本报文段所发送的数据的第一个字节的序号。
确认号(acknowledgement number):ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,ack=seq+1。是期望受到对方下一个报文段的第一个数据字节的序号。
标志位(Flags):共6个,即URG、ACK、PSH、RST、SYN、FIN等。具体含义如下:
URG:紧急指针(urgent pointer)有效。
ACK:确认序号有效。仅当ACK为1时确认号字段才有效。TCP规定,在连接建立后所有传送的报文段都必须把ACK设置为1
PSH:接收方应该尽快将这个报文交给应用层。
RST:重置连接。
SYN:在连接建立时同步序号。当 SYN=1, ACK=0 表示这是一个连接请求报文,对方若同意连接,则在响应把文段中使 SYN=1, ACK=1,SYN设置为1表示是一个连接请求或连接接收报文
FIN:释放一个连接。当FIN=1时,表示此报文段的发送方的数据发送完毕,并要求释放连接。
那么这些字段有什么作用呢?
seq序号、ack序号:用于确认数据是否准确,是否正常通信。
标志位:用于确认/更改连接状态。
2 HTTPS
HTTPS: HTTP 加上加密处理和认证以及完整性保护后即是 HTTPS 。HTTPS 并非是应用层的一种新协议。只是 HTTP 通信接口部分用 SSL(Secure Socket Layer)和 TLS(Transport Layer Security)协议代替而已。
通常,HTTP 直接和 TCP 通信。当使用 SSL 时,则演变成先和 SSL 通信,再由 SSL 和 TCP 通信了。
SSL 是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。SSL 采用一种叫做公开密钥加密(Public-key cryptography)的加密处理方式。
2.1 加密方式
共享密钥加密:加密和解密同用一个密钥的方式,也被叫做对称密钥加密。发送方将报文和密码发送给接收方,接收方收到后使用密钥解密。在此过程中,报文有可能被窃取,那么密钥也有可能被窃取。
公开密钥加密:使用一对非对称的密钥。一把叫做私有密钥,另一把叫做公开密钥。发送密文的一方使用对方的公开密钥进行加密处理,对方收到被加密的信息后,再使用自己的私有密钥进行解密。利用这种方式,不需要发送用来解密的私有密钥,也不必担心密钥被攻击者窃听而盗走。
HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。比如,正准备和某台服务器建立公开密钥加密方式下的通信时,如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。
可以使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书。
2.2 HTTPS 通信
步骤 1: 客户端发送 Client Hello报文,包含加密算法集,SSL 版本,随机数。
步骤 2: 服务器可进行 SSL 通信时,会发送 Server Hello 报文作为应答,包含加密算法集,SSL 版本,随机数。
步骤 3: 之后服务器发送 Certificate 报文,附加服务器的证书,包含公开密钥。
步骤 4: 然后服务器发送 Server Hello Done 报文通知客户端,最初阶段的 SSL 握手协商部分结束。
步骤 5: 客户端收到消息后会去验证是否为可信的证书机构签发的,是否为真实的服务器,之后使用证书附带的公钥生成 premaster secret 作为 Client Key Exchange 消息体发送给服务器。
步骤 6:服务器收到后使用私钥解密 premaster secret。
步骤 7:客户端和服务器使用premaster secret和对方的随机数生成相同的 master key 用于加密和解密后续的通信。
步骤 8: 接着客户端继续发送 Change Cipher Spec 报文。
步骤 9: 客户端发送使用 master key 加密的Finished消息。
步骤 10: 服务器接受并验证,同样给浏览器发送 Change Cipher Spec 消息。
步骤 11: 服务器发送使用 master key 加密的Finished消息。
步骤 12: 客户端接受并验证,握手完成。当然,通信会受到 SSL 的保护。从此处开始进行应用层协议的通信,即发送 HTTP 请求。
步骤 13: 应用层协议通信,即发送 HTTP 响应。
步骤 14: 最后由客户端断开连接。断开连接时,发送 close_notify 报文。这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。
2.3 为什么不一直使用 HTTPS
既然 HTTPS 那么安全可靠,那为何所有的 Web 网站不一直使用 HTTPS ?
其中一个原因是,因为与纯文本通信相比,加密通信会消耗更多的 CPU 及内存资源。节约购买证书的开销也是原因之一。
3 HTTP 与 HTTPS 的区别
HTTPS 协议是由 SSL/TLS + HTTP 协议构建的可进行加密传输、身份认证的网络协议,要比 HTTP 协议安全。
HTTPS 协议的主要作用可以分为两种:一种是建立一个信息安全通道,来保证数据传输的安全;另一种就是确认网站的真实性。
HTTPS 和 HTTP的主要区别:
1.HTTPS 协议需要到CA申请证书,一般免费证书较少,因而需要一定费用。
2.HTTP 是超文本传输协议,信息是明文传输,数据都是未加密的,安全性较差,HTTPS(SSL+HTTP) 数据传输过程是加密的,安全性较好。
3.HTTP 和HTTPS 使用的是完全不同的连接方式,用的端口也不一样,前者是80,后者是443。
4.HTTP 的连接很简单,是无状态的;HTTPS 协议是由 SSL/TLS + HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 HTTP 协议安全。
5.HTTP 页面响应速度比 HTTPS 快,主要是因为 HTTP 使用 TCP 三次握手建立连接,客户端和服务器需要交换 3 个包,而 HTTPS 除了 TCP 的三个包,还要加上 SSL 握手需要的 9 个包,所以一共是 12 个包。
6.HTTPS 其实就是建构在 SSL/TLS 之上的 HTTP 协议,所以,要比较 HTTPS 比 HTTP 要更耗费服务器资源。
4 TCP与UDP的区别
1.TCP服务
面向连接,客户机/服务器进程间需要建立连接;可靠的传输。
流量控制: 发送方不会发送速度过快,超过接收方的处理能力。
拥塞控制: 作用于网络,它是防止过多的包被发送到网络中,避免出现网络负载过大,网络拥塞的情况。
不提供时间/延迟保障、不提供最小带宽保障。
应用场景:效率要求相对低,但对准确性要求相对高的场景。可用于文件传输(ftp)、邮件传输(smtp)、HTTP
2.UDP服务
无连接、不可靠的数据传输
不提供:可靠性保障、流量控制、拥塞控制、延迟保障、带宽保障
应用场景:效率要求相对高,对准确性要求相对低的场景。可用于一些流媒体,比如:聊天、视频、语音电话。
5 TCP 的拥塞控制
TCP 拥塞控制:作用于网络,它是防止过多的包被发送到网络中,避免出现网络负载过大,网络拥塞的情况。
发送方维持一个叫做拥塞窗口的状态变量。拥塞窗口的大小取决于网络的拥塞程度,并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口。
发送方控制拥塞窗口的原则:只要网络没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多的分组发送出去,这样就可以提高网络的利用率。但只要网络出现拥塞或可能出现拥塞,就必须把拥塞窗口减小一些,以减少注入到网络中的分组数,以缓解网络出现的拥塞。
拥塞算法:慢开始、拥塞避免、快重传、快恢复
慢开始:在开始发送信息时,由于不知道具体的网络环境,为避免大量信息造成的拥塞现象,试探网络的拥塞程度,此时的拥塞窗口cwnd以最小值(即拥塞窗口和接收端窗口中的较小值)进行数据发送,由小到大逐渐增大拥塞窗口的数值,为避免拥塞窗口增长过大引起网络拥塞,设置一个慢开始门限(ssthresh 状态变量)。当cnwd < ssthresh,使用慢开始算法,以最小的拥塞窗口按照指数形式递增;当cnwd = ssthresh,既可使用慢开始算法,也可以使用拥塞避免算法;当cnwd > ssthresh,使用拥塞避免算法。
拥塞避免:让拥塞窗口cwnd缓慢的增大,即每经过一个返回时间RTT就把发送方的拥塞窗口加一。将拥塞窗口控制为按线性规律增长,使网络比较不容易出现拥塞。
当网络出现超时,发送方判断为网络拥塞,于是调整门限值ssthresh = cwnd/2,同时设置拥塞窗口cwnd = 1,进入慢开始阶段。
当拥塞窗口cwnd = ssthresh(到达新的门限值),执行拥塞避免算法。
当拥塞窗口增大到出现新的情况,发送方一连收到3个对同一报文段的重复确认,执行快重传算法。发送方知道只是丢失个别的报文段,不启动慢开始算法,执行快恢复算法。
快重传:发送方只要连续收到三个重复确认就立即重传对方尚未收到的报文段,而不必继续等待设置的重传计时器时间到期。使用快重传可以提高整个网络的吞吐率。
快恢复:当发送方连续收到三个重复确认时,调整门限值 = cwnd / 2, 将cwnd设置为ssthresh的大小, 然后执行拥塞避免算法。
6 TCP 的流量控制
TCP 的流量控制:如果发送端发送数据太快,接收端来不及接收,可能会丢失数据。通过滑动窗口来进行流量控制,它是控制发送方的发送速度从而使接受者来得及接收并处理。窗口大小的单位是字节,不是报文段。
接收方每次收到数据包,可以在发送确定报文的时候,同时告诉发送方自己的缓存区还剩余多少是空闲的,我们也把缓存区的剩余大小称之为接收窗口大小,用变量win来表示接收窗口的大小。
发送方收到之后,便会调整自己的发送速率,也就是调整自己发送窗口的大小,当发送方收到接收窗口的大小为0时,发送方就会停止发送数据,防止出现大量丢包情况的发生。
7 get与post的区别
1.get在浏览器回退时是无害的,而post会再次提交请求。
2.get请求会被浏览器主动缓存,而post不会,除非手动设置。
3.get请求参数会被完整保留在浏览器历史记录里,而post中的参数不会被保留。
4.get参数通过url传递,post放在 request body 中。
5.get请求在url中传送的参数是有长度限制的,而post没有限制。
6.get比post更不安全,因为参数直接暴露在url上,所以不能用来传递敏感信息。
8 输入 url 的发生过程
9 HTTP常见状态码
100 Continue:继续,客户端应继续其请求。
101 Switching Protocols: 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议,例如,切换到HTTP的新版本协议。
200 OK:客户端请求成功。
301 Moved Permanently:所请求的页面都已经转移至新的url。
302 Found:所请求的页面已经临时转移至新的url。
304 Not Modified:客户端有缓冲的文档并发出了一个条件性的请求,服务器告诉客户端,原来缓冲的文档还可以继续使用。
400 Bad Request:客户端请求有语法错误,不能被服务器所理解
401 Unauthorized: 请求未经授权,这个状态代码必须和WWW-Authenticate报头域一起使用。
403 Forbidden:对被请求页面的访问被禁止。
404 Not Found:请求资源不存在。
500 Internal Server Error:服务器发生不可预期的错误。
502 Bad Gateway:作为网关或者代理工作的服务器尝试执行请求时,从远程服务器接收到了一个无效的响应。
503 Server Unavailable:请求未完成,服务器临时过载或宕机,一段时间后可能恢复正常。
504 Gateway Timeout:表示扮演网关或者代理的服务器无法在规定的时间内获得想要的响应。
参考链接
web前端经典面试题试题及答案-前后端通信(HTTP、HTTPS、tcp)
10 HTTP缓存
HTTP缓存能够帮助服务器提高并发性能,很多资源不需要重复请求,直接从浏览器中拿缓存。
HTTP缓存分类:强缓存、协商缓存
1.强缓存
向浏览器缓存查找该请求结果,并根据该结果的缓存规则来决定是否使用该缓存结果的过程,浏览器不会将请求发送给服务器。
在 Chrome 的开发者工具中看到HTTP的状态码是 200,在 Size 列会显示为(from cache)。利用HTTP的响应头中的 expires 或者 cache-control 两个字段来控制的,用来表示资源的缓存时间、缓存类型等。
cache-control 比 expires 优先级高,并且expires是缓存过期时间的绝对时间,存在浏览器与服务端时间不同步的问题,cache-control 缓存的过期时间是相对时间。
2.协商缓存
协商缓存就是强制缓存失效后,浏览器携带缓存标识向服务器发起请求,由服务器根据缓存标识决定是否使用缓存的过程。利用HTTP响应头中的 ETag、Last-Modified 两个字段进行控制。
为什么存在 Last-Modified 还会有 ETag ?
Last-Modified 是资源最后更改的时间。ETag HTTP响应头是资源的特定版本的标识符。这可以让缓存更高效,并节省带宽,因为如果内容没有改变,Web服务器不需要发送完整的响应。而如果内容发生了变化,使用 ETag 有助于防止资源的同时更新相互覆盖(“空中碰撞”)。
Last-Modified 只能精确到秒,如果某些文件在1秒钟以内,被修改多次的话,它将不能准确标注文件的修改时间,所以在秒级以下的更改无法检测到。而 ETag 可以表明文件的任何更改,只要文件变化 ETag 就会变化。所以 Last-Modified 是一个备用机制,优先级不如 Etag。
请求步骤:
请求资源时,把用户本地该资源的 ETag 同时带到服务端,服务端和最新资源做对比。
如果资源没更改,返回状态码 304,浏览器读取本地缓存。
如果资源有更改,返回状态码 200,返回最新的资源。
11 网络安全攻击
11.1 XSS
XSS(Cross Site Scripting)跨站脚本攻击,是最普遍的 Web 应用安全漏洞。这类漏洞能够使得攻击者嵌入恶意脚本代码到正常用户会访问到的页面中,当正常用户访问该页面时,则可导致嵌入的恶意脚本代码的执行,从而达到恶意攻击用户的目的。XSS攻击最主要有如下分类:持久型 XSS、非持久型 XSS、DOM XSS。
1.持久型 XSS :最直接的危害类型,跨站代码存储在服务器(数据库)。
2.非持久型 XSS :反射型跨站脚本漏洞,最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。
3.DOM XSS :DOM(document object model文档对象模型),客户端脚本处理逻辑导致的安全问题。
基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置,而使得攻击脚本被执行。在整个攻击过程中,服务器响应的页面并没有发生变化,引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。
跨站脚本攻击有可能造成以下影响:
1.利用虚假输入表单骗取用户个人信息。
2.利用脚本窃取用户的 Cookie 值,被害者在不知情的情况下,帮助攻击者发送恶意请求。
3.显示伪造的文章或图片。
防御措施:
1.用户向服务器上提交的信息要对 URL 和附带的的 HTTP 头、POST 数据等进行查询,对不是规定格式、长度的内容进行过滤。
2.实现 Session 标记(session tokens)、CAPTCHA 系统或者 HTTP 引用头检查,以防功能被第三方网站所执行。
3.确认接收的的内容被妥善的规范化,仅包含最小的、安全的 Tag(没有javascript),去掉任何对远程内容的引用(尤其是样式表和 javascript ),使用 HTTP only 的cookie。
11.2 CSRF
CSRF(Cross-site Request Forgery)跨站请求伪造,是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作(如发邮件,发消息,甚至财产操作如转账和购买商品)。由于浏览器曾经认证过,所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞:简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求本身是用户自愿发出的。
防御措施:
1.检查 Referer 字段
HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址。
2。添加校验 token
由于 CSRF 的本质在于攻击者欺骗用户去访问自己设置的地址,所以如果要求在访问敏感数据请求时,要求用户浏览器提供不保存在cookie中,并且攻击者无法伪造的数据作为校验,那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中,其内容是一个伪随机数。当客户端通过窗体提交请求时,这个伪随机数也一并提交上去以供校验。
11.3 SQL 注入攻击
SQL 注入(SQL Injection)是指针对 Web 应用使用的数据库,通过运行非法的 SQL 而产生的攻击。该安全隐患有可能引发极大的威胁,有时会直接导致个人信息及机密信息的泄露。 Web 应用通常都会用到数据库,当需要对数据库表内的数据进行检索或添加、删除等操作时,会使用 SQL 语句连接数据库进行特定的操作。如果在调用 SQL 语句的方式上存在疏漏,就有可能执行被恶意注入(Injection)非法 SQL 语句。
SQL 注入攻击有可能会造成以下等影响:
1.非法查看或篡改数据库内的数据
2.规避认证
3.执行和数据库服务器业务关联的程序等
- 本文作者: étoile
- 版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!