HTTP

特点

• HTTP 协议构建于 TCP/IP 协议之上，是一个应用层协议，默认端口号是 80
• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。
• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传。

请求方式

• GET：请求获取Request-URI标识的资源，请求参数附加在url上，明文展示。
• POST：在Request-URI所标识的资源后附加新的数据，常用于修改服务器资源或者提交资源到服务器。POST请求体是放到body中的，可以指定编码方式，更加安全。
• HEAD：请求获取由Request-URI所标识的资源的响应消息报头。
• PUT：请求服务器存储一个资源，并用Request-URI作为其标识。
• DELETE：请求服务器删除Request-URI所标识的资源。
• TRACE：请求服务器回送收到的请求信息，主要用于测试或诊断。
• OPTIONS：请求查询服务器的性能，或者查询与资源相关的选项和需求。

请求和响应报文

• 请求报文包含：方法、URL、协议版本（基本为1.0.0版本）、CRLF、首部字段名：值、CRLF（多个首部字段名）、CRLF、实体主体（post具备主体，get不具备）

• 响应报文：版本、状态码、短语、CRLF、首部字段名：值、CRLF（多个首部字段名）、CRLF、实体主体

  
  请求报文.png
  响应报文.png

状态码

• 1xx，2xx(200请求成功)，3xx（301，302网络请求发生异常，网络重定向等），4xx（401，404客户端请求发生某些问题），5xx（502，501，sever端的异常）
• 200 OK 客户端请求成功
  301 Moved Permanently 请求永久重定向
  302 Moved Temporarily 请求临时重定向
  304 Not Modified 文件未修改，可以直接使用缓存的文件。
  400 Bad Request 由于客户端请求有语法错误，不能被服务器所理解。
  401 Unauthorized 请求未经授权。这个状态代码必须和WWW-Authenticate报头域一起使用
  403 Forbidden 服务器收到请求，但是拒绝提供服务。服务器通常会在响应正文中给出不提供服务的原因
  404 Not Found 请求的资源不存在，例如，输入了错误的URL
  500 Internal Server Error 服务器发生不可预期的错误，导致无法完成客户端的请求。
  503 Service Unavailable 服务器当前不能够处理客户端的请求，在一段时间之后，服务器可能会恢复正常。

get、post区别

• get以问号分割（长度限制在2048字节以内）post放到body体重（长度无限制）
• get是明文传输，安全性上来将，post更为安全

连接建立流程

• 连接建立需要三次握手：发送SYN（client发送连接请求），返回SYNACK（server确认），再次ACK（client确认）
• 进行请求
• 发送回应

• 连接断开需要四次挥手：FIN（client发送请求终止报文），ACK（server确认报文），FINACK（某一时机，server再次发送断开连接报文），ACK（client确认报文）

  
  HTTP的连接过程.png

判断一个请求是否已经结束

• 查看请求或响应报文头部字段的content-length：1024，达到这个值，标识请求或者发送已经完毕
• post请求时，chunked（头部字段中），最后会有一个空的chunked

HTTP持久连接

• 非持久连接，每次请求都需要client和server创建新的链接和断开连接
• 持久连接，打开一条通道，可能会长久的保持这一条TCP通道，不用每次都进行三次握手，四次挥手

• 持续时间放在请求体的头部来告知server端

  
  持久连接.png

Charles抓包原理

• 中间人攻击
• 在client和server端中间的TCP链接，添加一个中间端服务器，假冒终端server来进行通信，可以篡改数据

HTTPS

概念

• HTTPS = HTTP + TLS/SSL，它使用的端口默认为443
• 插在应用层之下，传输层之上的一个安全协议

HTTPS协议栈.png

建立流程

1、客户端首次请求服务器，告诉服务器自己支持的协议版本，支持的加密算法及压缩算法，并生成一个随机数（client random）告知服务器。
2、服务器确认双方使用的加密方法，并返回给客户端证书以及一个服务器生成的随机数（server random）
3、客户端收到证书后，首先验证证书的有效性，然后生成一个新的随机数（premaster secret），并使用数字证书中的公钥，加密这个随机数，发送给服务器。
4、服务器接收到加密后的随机数后，使用私钥进行解密，获取这个随机数（premaster secret
5、服务器和客户端根据约定的加密方法，使用前面的三个随机数（client random, server random, premaster secret），生成『对话密钥』（session key），用来加密接下来的整个对话过程（对称加密）。

HTTPS加密的过程.png

会话密钥

• 会话密钥 代表的是对称加密的一个结果。
• 会话密钥 = 一定的算法(random S + random C + 预主密钥)

问题一：为什么握手过程需要三个随机数，而且安全性只取决于第三个随机数？

前两个随机数是明文传输，存在被拦截的风险，第三个随机数是通过证书公钥加密的，只有它是经过加密的，所以它保证了整个流程的安全性。前两个随机数的目的是为了保证最终对话密钥的『更加随机性』。

问题二：Charles如何实现HTTPS的拦截？

Charles要实现对https的拦截，需要在客户端安装Charles的证书并信任它，然后Charles扮演中间人，在客户端面前充当服务器，在服务器面前充当客户端。

问题三，HTTPS都使用了哪些加密方法，为什么

• 连接过程中使用非对称加密，公钥加密私钥解密，私钥存放在解密放，这样能最大程度的保证数据传输的安全性
• 后续过程中，使用对称加密，双方使用同一个公钥进行加密，因为非对称加密消耗性能很大，所以后续的过程使用对称加密

DNS

概念

域名到IP的映射，DNS解析采用UDP数据报形式，且为明文传送

解析流程

1、浏览器中输入想要访问的网站域名，操作系统会检查本地hosts文件是否有这个网址的映射关系，如果有就调用这个IP地址映射，完成域名解析。没有的话就走第二步。
2、客户端回向本地DNS服务器发起查询，如果本地DNS服务器收到请求，并可以在本地配置区域资源中查到该域名，就将对应结果返回为给客户端。如果没有就走第三步。
3、根据本地DNS服务器的设置，采用递归或者迭代查询，直至解析完成。

• client发送请求，先把域名发送给DNS服务器，然后服务器返回对应的IP，然后通过IP，来向server发送数据
• 两种不同的解释

DNS解析查询

• 递归查询：查询层级：client -> 本地DNS -> 根域DNS -> 顶级DNS -> 权限DNS，查询到之后再层层返回
• 迭代查询：client -> 本地DNS，之后本地DNS会去询问可能知道的DNS：根域DNS、权限DNS、顶级DNS

DNS劫持问题

• 被劫持的原因：client发送域名并获取，是使用UDP的方式且明文的，此时可能存在钓鱼的DNS服务器来劫持域名并返回错误的IP，进而访问错误的网站
• 解决劫持问题
  1. httpDNS（请求返回方式转变）：
     使用http协议想DNS服务器的80端口进行请求，不产生正产的解析步骤，client使用HTTP GET 请求httpDNS server，通过http响应报文来获取地址
  2. 长链接（内网专线）
     client 和 APIServer之间创建一个长链接通道，APIServer通过内网专线来进行网络通信

DNS劫持和HTTP的关系

• 么有关系，DNS解析是发生在HTTP建立连接之前的
• DNS解析请求使用的是UDP数据报，端口号53

解析转发问题

client发送域名，DNS为了节省资源，会转发给其他的DNS服务器，其他DNS服务器会向权威的DNS服务器来请求域名对应的IP，此时可能涉及的并不是原来网络的节点，产生一个跨网访问的问题，造成网络访问的缓慢

Session / Cookie

存在意义

HTTP协议无状态特点的补偿

Cookie

• 主要用来记录用户状态，区分用户；状态保存在客户端
• client发送请求，server生成Cookie，通过响应报文+Cookie发送给client端。client保存Cookie，后续的请求在请求报文的头字段，添加Cookie来进行通信，server对Cookie识别来区别用户
• client端发送的Cookie在http请求报文的Cookie首部字段中
• server端设置http响应报文的set-Cookie首部字段

如何修改Cookie

• 新Cookie覆盖旧Cookie
• 覆盖规则：name、path、domain等需要与原Cookie一致

如何删除Cookie

• 新Cookie覆盖旧Cookie
• 覆盖规则：name、path、domain等需要与
• 设置Cookie的expires = 过去的一个时间点（此时就表示此Cookie是失效的），或者maxAge= 0

如何保证Cookie的安全性

• 对Cookie进行加密处理
• 只在https上携带Cookie
• 设置Cookie为httpOnly，防止跨站脚本攻击

Session

概念

用来记录用户状态，区分用户；状态保存在服务器端

Session的工作流程

• client发送消息，server端记录用户状态，生成SessionID
• sever端通过set-Cookie拼接Sessionid发给client
• 后续的请求发送，Cookie、Sessionid给server端
• server识别Sessionid来识别用户

依赖关系和区别

1、存储位置：Cookie存放在客户端上，Session数据存放在服务器上。
2、Session 的运行依赖 session id，而 session id 是存在 Cookie 中的，也就是说，如果浏览器禁用了 Cookie ，同时 Session 也会失效
3、安全性：Cookie存在浏览器中，可能会被一些程序复制，篡改；而Session存在服务器相对安全很多。
4、性能：Session会在一定时间内保存在服务器上，当访问增多，会对服务器造成一定的压力。考虑到减轻服务器压力，应当使用Cookie

UDP

特点

• 无连接：不需要创建和销毁链接、速度快
• 尽最大努力交付：不保证可靠传输
• 传输面向报文
• 可以复用：不同的端口可以复用同一个UDP的数据报文，然后经由IP进行传输
• 可以分用：接收方可以根据UDP的目的端口，拆分端口，进行分发数据
• 差错检测功能：由三部分构成：
  1. 12字节伪首部
  2. 8字节UDP首部
  3. 7字节数据
     在2中，我们以16位字为一个单元，按二进制反码计算出这些16位字的和， 将和的二进制反码写入到检验和位（位于8字节UDP首部末尾），通过校验和位来判断UDP是否可用

TCP

特点

• 面向连接：连接需要进行三次握手
• 断开连接需要进行四次挥手
• 三次握手的原因：假如client发送超时，client会一句超时重传策略重新发送数据，server返回链接相应（假如此时为两次握手，那么此时TCP传输链接就建立了，但是，我们的server端后续又收到了，超时的client请求，那么server就会认为，client又要建立一条新的TCP链接，但是此时我们的client端本来只是需要建立一次链接），假如为三次握手的话，client端会再次发送确认建立的ACK确认报文，而超时的请求则没有发送确认请求的ACK报文，那么server端就能区分出一个为正常的请求，另一个为超时的请求，从而建立一条TCP链接

功能

• 无差错：数据间来回传递消息，没有中间差错
• 不丢失：这边通过client端开启重传机制，来对进行超时重传，确认丢失重传，确认迟到重传（在这里，假如迟到的消息报文再次达到客户端时，只是进行一个接受，但是什么操作也不会执行），来保证数据的完整性
• 面向字节流：发送的字节由TCP来确定的，不管发送方发送，多大的数据，我们都由TCP来进行一个划分

• 流量控制

  
  流量控制.png

• 控制拥塞机制

  
  拥塞机制.png

简述TCP慢启动的特点

发送报文指数增长，来试探拥塞的极限在哪，到门限初始值（16），减缓发送报文速率，加一递增，到24时，（连续三次ACK都未收到时，定义为网络拥塞），乘法减小发送报文到1，然后再指数增加，加法增加，慢慢恢复报文发送数量，门限值也减小到12（慢开始，拥塞避免算法）

TCP和UDP的区别

• TCP是面向链接的，支持可靠传输，面向字节流和提供了流量的控制和拥塞的控制
• UDP只是提供了简单的复用，分用，以及基本层的传输功能，UDP是无连接的
• TCP和UDP是传输协议

长链接和短链接

• 短连接：
  连接 -> 传输数据->关闭连接。就建立一次，但任务结束就中断连接。
  http链接属于短链接，因为它每次链接之后都会主动断开连接

• 长连接：
  连接 -> 传输数据 -> 保持连接 -> 传输数据。。。-> 关闭连接。是指连接后不管是否使用都保持连接，但安全性较差。

• 长连接、短连接用法：
  长连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况下。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理 速度会降低很多，所以每个操作完后都不断开，下次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成Socket错误，而且频繁的Socket创建也是对资源的浪费。

  而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接 会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下 需用短连好。

总之，长连接和短连接的选择要视情况而定。

socket

概念

• 套接字(socket)是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。
• 应用层通过传输层进行数据通信时，TCP会遇到同时为多个应用程序进程提供并发服务的问题。多个TCP连接或多个应用程序进程可能需要通过同一个 TCP协议端口传输数据。为了区别不同的应用程序进程和连接，许多计算机操作系统为应用程序与TCP／IP协议交互提供了套接字(Socket)接口。应用层可以和传输层通过Socket接口，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。
  网络层.png
• 它的作用是为了应用层能够更方便的将数据经由传输层来传输。所以它的本质就是对TCP/IP的封装，然后应用程序直接调用socket API即可进行通信。上文中说的三次握手和四次挥手即是通过socket完成的。

建立socket连接

建立 Socket 连接至少需要一对套接字，其中一个运行于客户端，称为ClientSocket，另一个运行于服务器端，称为ServerSocket。

套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认。

Socket连接与TCP连接

创建Socket连接时，可以指定使用的传输层协议，Socket可以支持不同的传输层协议（TCP或UDP），当使用TCP协议进行连接时，该Socket连接就是一个TCP连接。

QQ、微信为什么是UDP而不是TCP:

像腾讯QQ之类的大规模即时通讯软件，经常性的是几千万用户同时在线 如果都采用长连接的方式。岂不是要服务器的硬件防火墙监控数千万个连接了，就算分布式服务端能承受这么多用户 网关也受不了，而且有理由相信服务器也受不了 。所以对于大规模即时通讯，尤其是用户数量众多 肯定不能用TCP常连接的方式，这种方式只适合于小规模的即时通讯，如局域网，公司内部的即时通讯等 对于大规模的，用户数量众多的C/S软件 应当采用UDP协议进行数据传输，网关就不停收发数据包就可以了。

使用TCP协议和客户端进行短命连接，用了就关 比如客户登陆请求好友列表，我们就和他建立TCP连接发给他好友列表，然后关掉连接 当用户要给另外一个客户发信心我们再建立连接，数据传完我们又关掉连接 这种方式，无疑服务器可以承载更多的用户登陆。但是缺点也是非常明显的 一般情况下我们接收的数据都不大，每次发一点点消息都要建立连接 TCP本来就比较消耗网络资源，这样毫无规律的断断连连 连连断断，加上本来这种方式就有较高的延迟 也不适合大规模的即时通讯

事实上，在Internet上传输的UDP包从A发送给B 它完整地到达几率一般情况下还是相当之高的。我们开发一个多用户的即时通讯软件 采用UDP传输消息的时候，报文被划分成包 一个UDP包究竟是多大？经过我的了解一个UDP用户包最大大小是64KB 根据网络状况，实际在传输包的时候可能把包划成若干个分片 一个分片的最大大小是1640B 可以保存好几百个汉字。UDP协议提供数据报机制传输信息 如果报文比较长，比如一个文件，一个图片 要被划分成若干个数据包，由于对于一般的文字消息和其它指令都是比较小的 它们会被放在一个包里面，由于UDP是无连接的 不可靠的，如果发生丢包，不会重传 所以不能保证数据包能完整并准确地到达目的地，但是对于我们的即时通讯软件来说 一般的聊天信息比较小，比如我们给一个好友发送一条聊天信息“今天我很高兴”，会不会服务器转发的时候只收到“今天我很高”，再传给好友的时候变成了“今天”，答案是不会发生这种情况的 UDP虽然描述是不可靠，不过依然在数据包中包含了头信息描述了包的大小等信息，在包进行转发的过程中 如果数据不完整，是会被网络设备发现的，比如中途一个转发这个包的路由器发现了一个不完整的UDP包会直接丢弃，如果是TCP 当有包被丢弃了会进行重传，对于UDP 包在传输过程中由于数据的缺失被丢弃不会进行重传 我们顶多就是一条信息发送失败了，而这种概率一般情况下是非常低的 。

开发时到底选择TCP还是UDP:

如果是由客户端间歇性的发起无状态的查询，并且偶尔发生延迟是可以容忍，那么使用HTTP/HTTPS吧。

如果客户端和服务器都可以独立发包，但是偶尔发生延迟可以容忍（比如：在线的纸牌游戏，许多MMO类的游戏），那么使用TCP长连接吧。

如果客户端和服务器都可以独立发包，而且无法忍受延迟（比如：大多数的多人动作类游戏，一些MMO类游戏），那么使用UDP吧。

WebRTC是干什么用的

WebRTC是一个可以用在视频聊天，音频聊天或P2P文件分享等Web App中的 API。借助WebRTC，你可以在基于开放标准的应用程序中添加实时通信功能。它支持在同级之间发送视频，语音和通用数据，从而使开发人员能够构建功能强大的语音和视频通信解决方案。该技术可在所有现代浏览器以及所有主要平台的本机客户端上使用。WebRTC项目是开源的，并得到Apple，Google，Microsoft和Mozilla等的支持。

如果某一请求只在某一地特定时刻失败率较高，会有哪些原因

这个是某公司二面时的问题，是一个开放性问题，我总结了以下几点可能：

1、该时刻请求量过大

2、该地的网络节点较不稳定

3、用户行为习惯，比如该时刻为上班高峰期，或者某个群体的特定习惯

总结

• HTTP、HTTPS，是应用层的应用协议，HTTP 协议构建于 TCP/IP 协议之上，是一个应用层协议，默认端口号是 80，HTTPS = HTTP + TLS/SSL，它使用的端口默认为443
• TCP、UDP是传输协议，传输层，建立连接使用TCP，UDP是无连接的，直接发送数据
• socket 是支持TCP/IP协议的网络通信的基本操作单元，创建时可以指定传输层协议