计算机网络

1、  TCP与UDP区别，优缺点

TCP---传输控制协议,提供的是面向连接、可靠的字节流服务。当客户和服务器彼此交换数据前，必须先在双方之间建立一个TCP连接，之后才能传输数据。TCP提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。（HTTP、FTP）

UDP---用户数据报协议，是一个简单的面向数据报的传输层协议。UDP不提供可靠性，它只是把应用程序传给IP层的数据报发送出去，但是并不能保证它们能到达目的地。由于UDP在传输数据报前不用在客户和服务器之间建立一个连接，且没有超时重发等机制，故而传输速度很快。（DNS）

优缺点：

TCP---优：可靠，稳定  缺：传输慢，效率低，占用系统资源高，易被攻击

UDP—优：传输快  缺：不可靠，不稳定

2、  TCP与UDP的选择

当强调数据传输的完整性、可控制性和可靠性时，TCP协议是当然的选择。

当强调传输性能而不是传输的完整性时，如：语音视频和多媒体应用，UDP是最好的选择。在数据传输时间很短，以至于此前的连接过程成为整个流量主体的情况下，UDP也是一个好的选择，如：DNS交换。把SNMP建立在UDP上的部分原因是设计者认为当发生网络阻塞时，UDP较低的开销使其有更好的机会去传送管理数据。TCP丰富的功能有时会导致不可预料的性能低下

3、  UDP如何实现可靠传输

http://www.jianshu.com/p/6c73a4585eba

3、Tcp 三次握手 四次挥手

https://blog.csdn.net/qzcsu/article/details/72861891

4、  HTTPGET 和 POST的区别

1.      GET请求的数据会附在URL之后（就是把数据放置在HTTP协议头中），以?分割URL和传输数据，参数之间以&相连。如果是中文/其他字符，则直接把字符串用BASE64加密；POST把提交的数据则放置在是HTTP包的包体中。

2.      GET方式提交的数据有限的（这个限制是特定的浏览器及服务器对它的限制，其实HTTP协议规范没有对URL长度进行限制）；POST是没有大小限制的，起限制作用的是服务器的处理程序的处理能力。

3.      POST的安全性要比GET的安全性高。通过GET提交数据，用户名和密码将明文出现在URL上；使用GET提交数据更可能会造成Cross-site request forgery攻击。

4.      CSRF攻击：1.登录受信任网站A，并在本地生成Cookie。2.在不登出A的情况下，访问危险网站B。防御措施：使用Token抵御CSRF攻击. CSRF攻击要成功的条件在于攻击者能够预测所有的参数从而构造出合法的请求。一个更通用的做法是保持原有参数不变，另外添加一个参数Token，其值是随机的。这样攻击者因为不知道Token而无法构造出合法的请求进行攻击。

5、  HTTP和HTTPS

1.HTTP特性

l  HTTP构建于TCP/IP协议之上，默认端口号是80

l  HTTP是无连接无状态的

2.消息格式

HTTP请求行 Method SPRequest-URI SP HTTP-Version（eg: GET /index.html Http/1.1）

请求头

可选的消息体

2.HTTPS

超文本安全传输协议,和HTTP相比,多了一个SSL/TSL加密层的认证过程,端口为443

http协议直接放置在TCP协议之上，而https提出在http和TCP中间加上一层加密层。从发送端看，这一层负责把http的内容加密后送到下层的TCP，从接收方看，这一层负责将TCP送来的数据解密还原成http的内容。

HTTPS流程

 

1、   peer终端发送一个request，https服务端把支持的加密算法等以证书的形式返回一个身份信息（包含ca颁发机构和加密公钥等）。

2、   获取证书之后，验证证书合法性。

3、   随机产生一个密钥，并以证书当中的公钥加密。

4、   request https服务端，把用公钥加密过的密钥传送给https服务端。

5、   https服务端用自己的密钥解密，获取随机值（对称密钥）。

6、   之后双方传送数据都用此密钥加密后通信。

6、  HTTP304 502

http://www.cnblogs.com/rongxh7/archive/2010/05/15/1736291.html

客户端第一次发送请求时，服务器首先产生 Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存是否有效。

过程如下:

       1. 客户端请求一个页面（A）。

       2. 服务器返回页面A，并在给A加上一个Last-Modified/ETag包含在响应头中。

       3. 客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。

       4. 客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag 作为请求头的If-Modified-Since/If-None-Match的值，一起传递给服务器。

       5. 服务器检查该If-Modified-Since/If-None-Match(即前一次响应头中的Last-Modified或ETag），并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。

ETag(响应头) / If-None-Match(请求头)

Last-Modified(响应头) /If-Modified-Since(请求头)

 

502：作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。

504：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。

7、  HTTP缓存

https://mp.weixin.qq.com/s/qOMO0LIdA47j3RjhbCWUEQ

1.接收请求

2.解析请求报文

3.查询缓存中是否存在副本

4.当已缓存副本超过了文档的新鲜度限值，就认为对象过时了，在提供文档之前，缓存要再次与服务器进行确认，查看文档是否发生了变化（expires和Last-modified一起用），

Last-modified

服务器端文件的最后修改时间，需要和cache-control共同使用，是检查服务器端资源是否更新的一种方式。当浏览器再次进行请求时，会向服务器传送If-Modified-Since报头，询问Last-Modified时间点之后资源是否被修改过。如果没有修改，则返回码为304，使用缓存；如果修改过，则再次去服务器请求资源，返回码和首次请求相同为200，资源为服务器最新资源。

5.      创建响应、发送响应

8、  HTTP如何实现断点上传

实现断点续传的功能，通常都需要客户端记录下当前的下载进度，并在需要续传的时候通知服务端本次需要下载的内容片段。

断点续传相关的HTTP头Range和Content-Range字段

1.客户端下载一个1024K的文件，已经下载了其中512K

2.网络中断，客户端请求续传，因此需要在HTTP头中申明本次需要续传的片段：

Range:bytes=512000-

这个头通知服务端从文件的512K位置开始传输文件

3.服务端收到断点续传请求，从文件的512K位置开始传输，并且在HTTP头中增加：

Content-Range:bytes 512000-/1024000

并且此时服务端返回的HTTP状态码应该是206，而不是200。

9、  Cookie和session的区别

1、cookie数据存放在客户的浏览器上，session数据放在服务器上。

2、cookie不是很安全，别人可以分析存放在本地的COOKIE并进行COOKIE欺骗，考虑到安全应当使用session。

3、session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用COOKIE。

4、cookie中的数据字段太多会影响传输效率

5、所以个人建议：

   将登陆信息等重要信息存放为SESSION

   其他信息如果需要保留，可以放在COOKIE中

 

cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。

Cookie生成方式：服务器通过在HTTP的响应头设置（set-cookie）或者客户端脚本如JavaScript或者VBScript也可以生成cookie。

cookie的内容主要包括：名字，值，过期时间，路径和域。路径与域一起构成cookie的作用范围。若不设置过期时间，则表示这个cookie的生命期为浏览器会话期间，关闭浏览器窗口，cookie就消失。这种生命期为浏览器会话期的cookie被称为会话cookie。

会话cookie一般不存储在硬盘上而是保存在内存里，当然这种行为并不是规范规定的。若设置了过期时间，浏览器就会把cookie保存到硬盘上，关闭后再次打开浏览器，这些cookie仍然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享，比如两个IE窗口。而对于保存在内存里的cookie，不同的浏览器有不同的处理方式。

 

10、           XSS攻击

XSS 全称“跨站脚本”，是注入攻击的一种。其特点是不对服务器端造成任何伤害，而是通过一些正常的站内交互途径，例如发布评论，提交含有 JavaScript 的内容文本。这时服务器端如果没有过滤或转义掉这些脚本，作为内容发布到了页面上，其他用户访问这个页面的时候就会运行这些脚本。

11、           微信登录原理

https://www.biaodianfu.com/weixin-qrcode.html

1、每次用户打开PC端登陆请求，系统返回一个唯一的uid，并将uid的信息绘制成二维码返回给用户。这里的uid一定是唯一的，否则就会造成你登陆了其他用户的账号或者其他用户登陆你的账号。

2、当用户使用登陆后的微信扫描该二维码的时候，会将这个uid和手机上的微信账号及密码产生的token进行绑定，并上传到服务器。

3、WEB通过JS不断的向后端发起请求，查询有没有关于uid的登陆记录（uid和token是否存在于服务器上）。

网页客户端每500毫秒就向服务器发起ssl请求，请求当前二维码的登陆信息，如果返回结果201，则说明已经获取扫描二维码终端相同的账号登陆授权，当返回其他结果时，将在500毫秒之后重新发起请求。

 

1、你用浏览器打开http://wx.qq.com的时候，微信给你随机分配了一个链接，【相当于给你开了间房，房号1024，注意，只给你房号，没给你钥匙】，用二维码包装着，并且设置了有效时间【10分钟你不进房间，就给你取消】。这里面没有用户什么事情，所以不存在UID（user ID），只是一个随机的字母和数字组合。

2、二维码的转码规则是统一的，所以意味着，只要是个二维码扫描软件，谁都能拿到这个链接，微信可以扫出来，我查查也可以扫出来。

3、所以拿到链接没有用，重要的是谁拿到链接，微信拿到了，就可以从微信客户端发一条信息给服务器，告诉服务器，现在是谁使用了某个链接，其他二维码扫描软件，不能和微信服务器通话，所以毫无价值。【你拿到了房号，就给酒店老板打个电话，说是我，老板就知道张三又来开房了，其他人没有老板电话，知道房号也没用】

4、这时候，在你刚打开的浏览器窗口里面，就知道并显示了你的信息，理论上可以直接打开聊天窗口，但是为了不突兀不尴尬，微信选择再让你在手机上做一个确认操作。【你站到你的房间门口了，老板也知道你是张三了，并且把你的那个好基友也放到了你房间里，但是谁知道你基友会在房间里干点啥？如果他正好弯腰在捡肥皂，这时候恰好你后面有人经过，房门大开大家尴尬不尴尬？所以还是老板考虑周到，他要你在电话里确认一下才给你开门，你大可以等后面没人了再开门进去】。