HTTP与HTTPS面试题

HTTP

概念：

HTTP是从服务器端向客户端传输超文本的传输协议，它使浏览器更加高效。HTTP是一个无状态协议，同一个客户端发送的这一次的请求和上一次的请求毫无关联，HTTP服务器不会保存客户的任何信息。
请求报文的格式：请求行，首部行，空行，实体体
响应报文的格式：状态行，首部行，空行，实体体

常见的请求头：

 Accept：浏览器可接受的响应内容类型。
 Accept - Charset：浏览器可接受的字符集。
 Accept - Encoding：浏览器可接受的响应内容的编码方式，比如gzip。Servlet能够向支持gzip的浏览器返回经gzip编码的HTML页面。许多情形下这可以减少5到10倍的下载时间。
 Accept - Language：浏览器可接受的相应内容的语言列表。
 Authorization：用于表示HTTP协议中需要认证资源的认证信息。
 Connection：表示是否需要持久连接。如果Servlet看到这里的值为“Keep - Alive”，或者看到请求使用的是HTTP 1.1（HTTP 1.1默认进行持久连接），它就可以利用持久连接的优点，当页面包含多个元素时（例如Applet，图片），显著地减少下载所需要的时间。要实现这一点，Servlet需要在应答中发送一个Content - Length头，最简单的实现方法是：先把内容写入ByteArrayOutputStream，然后在正式写出内容之前计算它的大小。
 Content - Length：表示请求体的长度。
 Cookie：由SetCookie设置的一个HTTP协议。
 From：请求发送者的email地址，由一些特殊的Web客户程序使用，浏览器不会用到它。
 Host：初始URL中的主机和端口。
 If - Modified - Since：只有当所请求的内容在指定的日期之后又经过修改才返回它，否则返回304“Not Modified”应答。
 Pragma：指定“no - cache”值表示服务器必须返回一个刷新后的文档，即使它是代理服务器而且已经有了页面的本地拷贝。
 Referer：包含一个URL，用户从该URL代表的页面出发访问当前请求的页面。
 User - Agent：浏览器类型，如果Servlet返回的内容与浏览器类型有关则该值非常有用。
 UA - Pixels，UA - Color，UA - OS，UA - CPU：由某些版本的IE浏览器所发送的非标准的请求头，表示屏幕大小、颜色深度、操作系统和CPU类型。

请求方法：

 Get：用来请求访问被URI（统一资源标识符）标识的资源，被服务器解析后返回相应内容
 Post：向服务器传输信息， 向指定资源提交数据并进行处理
 Put：传输文件，并将其保存到URI指定的位置，要求在请求报文中包含文件内容
 Head：获取报文首部，用于验证URI的有效性，获取资源的更新信息
 Delete：按照指定的URI删除文件
 Options：查询针对URI指定的资源所支持的方法

Get方法和post方法的区别：

 Get请求会被浏览器主动缓存，post不会
 Get请求对URL参数长度有限制，post没有
 Get请求的参数会暴露在URL中，不安全。Post不会
 Get请求将数据放在URL中，post放在消息体中
 Get请求的参数必须是ASCII字符，post没有限制
 Get请求的只能进行URL编码，post有多种编码格式
 Get请求每次只会发送一个TCP包，浏览器会同时发送HTTP请求头和数据。Post每次发送两个TCP包，浏览器先发送请求头，当返回状态码为100时，浏览器才会发送数据

HTTP的工作过程：

 地址解析：通过DNS解析域名，得到ip地址
 封装HTTP请求数据包：将解析出来的信息整合，封装数据包
 封装为TCP包，并建立TCP连接
 客户端发送请求
 服务器响应
 服务器关闭TCP连接

状态码：

 1xx：提示信息----请求已接收，继续操作
 2xx：成功----请求已成功被接收
 3xx：重定向----要求完成请求必须更进一步操作
 4xx：客户端错误----请求存在语法错误/请求无法实现
 5xx：服务器错误----服务器未能实现合法的请求

常见的状态码：

 200：请求成功，信息在返回的响应报文中
 400：客户端存在语法错误，不能被服务器理解
 401：请求未经授权，要求用户身份验证
 403：服务器理解该请求，但拒绝执行
 404：请求的资源不存在，URL错误
 500：服务器内部错误，无法完成请求
 503：由于超载或系统维护，服务器暂时无法完成请求

HTTPS

概念：

HTTPS是通过计算机网络进行安全通信的传输协议，其经由HTTP进行通信，利用SSL/TLS建立安全通道，加密数据包。HTTPS的使用目的是提供对网站服务器的身份验证，同时保护交换数据的隐私和完整性

工作原理：

 客户端使用HTTPS的URL访问服务器，请求与服务器建立SSL安全连接
 服务器收到请求后，返回网站的证书信息（包括公钥）
 客户端、服务器端共同协商SSL/TLS连接的安全等级（加密等级）
 客户端根据加密等级建立会话秘钥，并利用网站公钥加密，再传送给网站
 服务器利用自己的私钥解密会话秘钥
 服务器再通过会话秘钥加密与客户端之间的通信

HTTP与HTTPS的区别：

 HTTP是明文传输，HTTPS是加密传输，HTTPS更加安全
 HTTPS基于传输层，HTTP基于应用层
 HTTPS需要ca证书，费用比较高
 HTTP的标准端口号是80，HTTPS的为443

HTTPS协议的优点：

 使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器
 HTTPS比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性
 HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

HTTPS协议的缺点：

 HTTPS握手阶段比较费时，会使页面加载时间延长50%，增加10%~20%的耗电。
 HTTPS缓存不如http高效，会增加数据开销。
 SSL证书需要钱，功能越强大的证书费用越高。
 SSL证书需要绑定IP，不能再同一个ip上绑定多个域名，ipv4资源支持不了这种消耗。

HTTP/2

概念：

HTTP/2是基于SPDY协议的，相对于HTTP 1.X更加高效，简单，减少网络延迟，实现低延迟高吞吐。HTTP/2并没有更改HTTP的语法，而是改变了客户端与服务端传输数据的方式，通过新的二进制帧层控制整个过程。

SPDY协议：

SPDY意为“speedy”更快，是Google开发的基于TCP的应用层协议，其目的在于通过压缩、优先级、多路复用方式提高网页加载时间和网页的安全性，该协议的核心思想在于减少TCP连接数，是对HTTP协议的增强

特性：

 二进制分帧层：HTTP/2 性能提升的核心就在于二进制分帧层，HTTP/2 将所有信息分割为更小的消息和帧，并使用二进制编码。这样一来，客户端和服务器采用统一规则，数据的传输效率也就高了，性能也会变好
 首部压缩：使用HPACK算法压缩首部及响应数据
 允许多路复用：基于二进制分帧层，HTTP/2实现了同时发送多向请求和响应，HTTP消息被分解为互不依赖的帧，乱序发送出去，并在另一端根据流ID和首部将他们重新组合在一起，解决HTTP1.0的队首阻塞问题，减少了tcp连接数，提高了浏览器性能
 请求优先级：客户端明确优先级，服务器根据优先级依次交互数据（不能过分迷信请求优先级，首先要考虑服务器是否支持请求优先级，其次要考虑高优先级的慢响应请求会阻塞其他资源的交互）
 服务端推送：服务器端可以向一个客户端请求发送多个响应，而不用每一个需要客户端明确要求

输入URL到页面加载显示：

 输入URL
 缓存解析：首先查看缓存中是否有记录，缓存的查找记录为：浏览器缓存 ->系统缓存 -> 路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录
 DNS解析：如果没有则通过DNS解析域名，得到ip地址
 封装HTTP请求数据包：浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息（请求方法，请求说明和请求附带的数据）
 封装TCP包：将这个http请求封装在一个tcp包中
 建立TCP连接
 客户端发送请求
 服务器返回响应
 页面渲染：浏览器根据服务器返回的响应来构建DOM树，根据外部样式，内部样式，内联样式构建一个CSS对象模型树，构建完成后和DOM树合并为渲染树（这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点），之后进行布局，布局主要是确定各个元素的位置和尺寸，绘制页面像素信息
 浏览器将各层的信息发送给GUI，GUI会将各层合成（composite），显示在屏幕上。
 断开TCP连接

HTTP的缓存控制

强缓存：

基本原理是：

所请求的数据在缓存数据库中尚未过期时，不与服务器进行交互，直接使用缓存数据库中的数据。当缓存未命中时，则重新向服务器请求数据

两个规则字段：

 Expire：其指定了一个日期/时间， 在这个日期/时间之后，HTTP响应被认为是过时的。但是它本身是一个HTTP1.0标准下的字段，所以如果请求中还有一个置了 “max-age” 或者 “s-max-age” 指令的Cache-Control响应头，那么 Expires 头就会被忽略。
 Cache-Control通用消息头用于在http 请求和响应中通过指定指令来实现缓存机制。其常用的几个取值有：
 private：客户端可以缓存
 public：客户端和代理服务器都可以缓存
 max-age=xxx：缓存的内容将在xxx 秒后失效
 s-max-age=xxx：同s-max-age，但仅适用于共享缓存(比如各个代理)，并且私有缓存中忽略。
 no-cache：需要使用协商缓存来验证缓存数据
 no-store：所有内容都不会缓存，强缓存和协商缓存都不会触发
 must-revalidate：缓存必须在使用之前验证旧资源的状态，并且不可使用过期资源。

协商缓存：

当强缓存过期未命中或者响应报文Cache-Control中有must-revalidate标识必须每次请求验证资源的状态时，便使用协商缓存的方式去处理缓存文件。

基本原理：

从缓存数据库中取出缓存的标识，然后向浏览器发送请求验证请求的数据是否已经更新，如果已更新则返回新的数据，若未更新则使用缓存数据库中的缓存数据

两个规则字段：

 etag是所请求的数据在服务器中的唯一标识
 last-modifind标识所请求资源最后一次修改的时间。
再次请求后：
在我们的请求中有这样两个字段if-modifind-since和if-none-match，两个字段分别对应着响应中的last-Modified和etag，用来对协商缓存进行判断：
 首先，如果在第一次请求中有etag和last-modified时，缓存数据库会保存这两个字段，并且在再次发起同样的请求时以if-none-match和if-modified-since发送保存的last-modified和etag数据。
 服务器收到请求后会以优先级if-none-match > if-modifind-since的顺序进行判断，如果资源的etag和if-none-match相等，即所请求的资源没有变化，此时浏览器即可以使用缓存数据库中的数据，此时http的请求状态码为304，请求的资源未变化。
 如果请求字段中没有if-none-match，就使用if-modified-since来判断。如果if-modified-since的值和所请求的资源时间一致，即所请求的资源相同，浏览器即可以使用缓存数据库中的数据。http状态码304。

常见的网络攻击方法和解决方案？

SQL注入

攻击手段：
某些服务器处理用户账号，是直接将账号字符串拼接到SQL语句中，如果黑客利用规则拼接类似1=1的判断语句，数据库中可能会产生异常行为。
解决方案：
在Java中使用prepareStatement类预编译SQL语句，把固定格式的SQL编译后放入数据库缓冲池中，之后传入的字符串都当作参数来处理，而不是SQL指令。

XSS（跨站脚本攻击）

攻击手段：
攻击者往Web页面插入恶意

CSRF（跨站请求伪造）

攻击手段：
用户登录受信任的A网站，产生Cookie，在没有登出A的情况下，访问了危险的B网站，B要求访问第三方站点（A），并发送一个请求（request），然后B就带着之前的Cookie（伪装成用户的名义）去请求。
解决方案：验证码

cookie，localStorage， sessionStorage三者区别

• cookie始终在同源的http请求中携带，即使不需要，cookie在浏览器和服务器中来回传递。而localStorage和sessionStorage一般用于本地存储，不会好服务器通信，也不会自动把数据发送给服务器。
• 存储大小不同，cookie为4kb左右；localStorage， sessionStorage可以达到5M
• 数据有效期不同，sessionStorage仅在同源窗口中有效，关闭浏览器窗口就消失了，cookie在过期时间前一直有效，即使在关闭浏览器之后(如果没有设置过期时间，关闭浏览器就过期了)，localStorage长期有效，除非主动删除
  l- ocalStorage， sessionStorage有现成的API， cookie需要程序员手动封装

Cookie和Session

• cookie和session都可以追踪会话状态，cookie也可以被用于保存用户的喜好等非敏感信息。
• session 在服务器端，cookie 在客户端（浏览器）
• session 默认被存在在服务器的一个文件里（不是内存）
• session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效（但是可以通过其它方式实现，比如在 url 中传递 session_id）
• session 可以放在文件、数据库、或内存中都可以。

TCP协议（传输控制协议）

建立TCP连接（三次握手）

1. 客户端发送SYN包到服务器端，并进入SYN_SENT（同步已发送）状态，等待服务器相应
2. 服务器接收到SYN包后，确认客户端的SYN，同时发送一个SYN+ACK包，并进入SYN_RECV（同步收到）状态
3. 客户端收到SYN+ACK包后，向服务器发送确认包ACK，发送完毕后，客户端和服务器进入TCP连接成功状态

释放TCP连接（四次挥手）

1. 客户端发起连接释放报文，并停止发送报文，释放数据报文首部，并进入终止等待1状态
2. 服务器收到释放报文，向客户端发送确认报文，并带上自己的序列号，进入关闭等待状态，客户端收到确认报文后，进入终止等待2状态，等待服务器发送连接释放报文
3. 服务器发送完最后的数据后，向客户端发送连接释放报文，并进入最后确认状态
4. 客户端收到连接释放报文后，向客户端发送确认报文，并进入时间等待状态（经过2MSL最长报文段寿命的时间后，客户端撤销相应的TCB，进入closed状态），服务器收到确认报文后，撤销相应的TCB，立即进入关闭状态

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

因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，所以只能先回复一个ACK报文，告诉Client端，“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。

为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

1. 保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
2. 防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

5. 如果已经建立了连接，但是客户端突然出现故障了怎么办？
   TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP和UDP的区别

1. TCP是面向连接的，udp是无连接的即发送数据前不需要先建立链接。
2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。 并且因为tcp可靠，面向连接，不会丢失数据因此适合大数据量的交换。
3. TCP是面向字节流，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）。
4. TCP只能是1对1的，UDP支持1对1,1对多。
5. TCP的首部较大为20字节，而UDP只有8字节。
6. TCP是面向连接的可靠性传输，而UDP是不可靠的。

前端性能优化：（减少客户端网络延迟和优化页面渲染性能来提升WEB性能）

减少HTTP请求数：

1. 合理设置HTTP缓存：
   很少变化的图片资源可以通过 HTTP 字段Expire设置一个很长的过期头 ，变化不频繁而又可能会变的资源可以使用 Last-Modifed来做请求验证。尽可能的让资源能够在缓存中待得更久。
2. 合并、压缩资源：
   尽可能的将外部的脚本、样式进行合并，多个合为一个。另外， CSS、 Javascript、Image 都可以用相应的工具进行压缩，压缩后往往能省下不少空间。（但是压缩文件，会降低代码可读性）
3. 使用CSS精灵合并css图片
4. Lazy Load Images（图片懒加载）：
   不能减少HTTP请求数，但可以缓解服务器的压力，使某些请求再需要的时候再加载。
5. 减少对cookie的使用（最主要的就是减少本地cookie存储内容的大小），因为客户端操作cookie的时候，这些信息总是在客户端和服务端传递。如果上设置不当，每次发送一个请求将会携带cookie

代码优化

1. 减少使用CSS表达式、js闭包
2. 减少对DOM操作（主要是减少重绘与回流）
3. css导入的时候不使用@import，使用link
4. 减少flash的使用
5. 避免使用iframe不仅不好管控样式，而且相当于在本页面又嵌套其他页面，消耗性能会更大。因为还回去加载这个嵌套页面的资源

网络安全

SQL注入

攻击手段：

某些服务器处理用户账号，是直接将账号字符串拼接到SQL语句中，如果黑客利用规则拼接类似1=1的判断语句，数据库中可能会产生异常行为。

解决方案：

在Java中使用prepareStatement类预编译SQL语句，把固定格式的SQL编译后放入数据库缓冲池中，之后传入的字符串都当作参数来处理，而不是SQL指令。

XSS（跨站脚本攻击）

攻击手段：

攻击者往Web页面插入恶意

解决方案：

过滤

CSRF（跨站请求伪造）

攻击手段：

用户登录受信任的A网站，产生Cookie，在没有登出A的情况下，访问了危险的B网站，B要求访问第三方站点（A），并发送一个请求（request），然后B就带着之前的Cookie（伪装成用户的名义）去请求。

解决方案：

验证码