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://img.haomeiwen.com/i7980283/8a8ff2d9434c7a8c.png)
建立流程
1、客户端首次请求服务器,告诉服务器自己支持的协议版本,支持的加密算法及压缩算法,并生成一个随机数(client random)告知服务器。
2、服务器确认双方使用的加密方法,并返回给客户端证书以及一个服务器生成的随机数(server random)
3、客户端收到证书后,首先验证证书的有效性,然后生成一个新的随机数(premaster secret),并使用数字证书中的公钥,加密这个随机数,发送给服务器。
4、服务器接收到加密后的随机数后,使用私钥进行解密,获取这个随机数(premaster secret
5、服务器和客户端根据约定的加密方法,使用前面的三个随机数(client random, server random, premaster secret),生成『对话密钥』(session key),用来加密接下来的整个对话过程(对称加密)。
![](https://img.haomeiwen.com/i7980283/c01e6506d57a59e2.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,进而访问错误的网站
- 解决劫持问题
- httpDNS(请求返回方式转变):
使用http协议想DNS服务器的80端口进行请求,不产生正产的解析步骤,client使用HTTP GET 请求httpDNS server,通过http响应报文来获取地址 - 长链接(内网专线)
client 和 APIServer之间创建一个长链接通道,APIServer通过内网专线来进行网络通信
- httpDNS(请求返回方式转变):
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的目的端口,拆分端口,进行分发数据
- 差错检测功能:由三部分构成:
- 12字节伪首部
- 8字节UDP首部
- 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协议的网络通信的基本操作单元,创建时可以指定传输层协议
网友评论