Tcp-Ip-Http

1.OSI与tcp/ip层的结构功能，都有哪些协议

(1)OSI七层模型

OSI中的层	功能	TCP/IP协议族
应用层	文件传输，电子邮件，文件服务，虚拟终端	TFTP，HTTP，SNMP，FTP，SMTP，DNS，Telnet
表示层	数据格式化，代码转换，数据加密	没有协议
会话层	解除或建立与别的接点的联系	没有协议
传输层	提供端对端的接口	TCP，UDP
网络层	为数据包选择路由	IP，ICMP，RIP，OSPF，BGP，IGMP
数据链路层	传输有地址的帧以及错误检测功能	SLIP，CSLIP，PPP，ARP，RARP，MTU
物理层	以二进制数据形式在物理媒体上传输数据	ISO2110，IEEE802，IEEE802.2

(2)TCP/IP五层模型的协议

应用层

传输层

网络层

数据链路层

物理层

1. TCP与UDP的区别
2. TCP报文结构
3. TCP三次握手
4. TCP四次挥手
5. TCP各个状态的名称与含义，TIMEWAIT的作用
6. TCP拥塞控制
7. TCP滑动窗口与回退N针协议
8. HTTP的状态码的含义
9. HTTP Request的几种类型

application/x-www-form-urlencoded

POST 提交数据的方式了。浏览器的原生 form 表单，如果不设置 enctype 属性，那么最终就会以 application/x-www-form-urlencoded 方式提交数据。

multipart/form-data

POST 数据提交的方式。我们使用表单上传文件时，必须让 form 的 enctyped 等于这个值。

application/json

用来告诉服务端消息主体是序列化后的 JSON 字符串。

由于 JSON 规范的流行，除了低版本 IE 之外的各大浏览器都原生支持 JSON.stringify，

服务端语言也都有处理 JSON 的函数，使用 JSON 不会遇上什么麻烦。

text/xml

1. http1.1和http1.0的区别
2. http1.1怎么处理长连接
3. 一个HTTP请求的全过程

https://blog.51cto.com/linux5588/1351007

https://blog.csdn.net/yezitoo/article/details/78193794

域名解析 --> 发起TCP的3次握手 --> 建立TCP连接后发起http请求 --> 服务器响应http请求，浏览器得到html代码 --> 浏览器解析html代码，并请求html代码中的资源（如js、css、图片等） --> 浏览器对页面进行渲染呈现给用户

 

1. 电脑上访问一个网页  DNS HTTP TCP OSPF IP ARP
2. Http请求中的GET和POST有什么区别

本质上没有任何区别。他们都是HTTP协议中的请求方法。底层实现都是基于TCP/IP协议。上述的所谓区别，只是浏览器厂家根据约定，做得限制而已。

 

HTTP请求，最初设定了八种方法。这八种方法本质上没有任何区别。只是让请求更加有语义而已。

 

OPTIONS 返回服务器所支持的请求方法

GET 向服务器获取指定资源

HEAD 与GET一致，只不过响应体不返回，只返回响应头

POST 向服务器提交数据，数据放在请求体里

PUT 与POST相似，只是具有幂等特性，一般用于更新

DELETE 删除服务器指定资源

TRACE 回显服务器端收到的请求，测试的时候会用到这个

CONNECT 预留，暂无使用

1. HTTP请求报文
2. HTTP响应报文
3. 域名解析的过程
4. ping的整个过程。ICMP报文是什么
5. IP地址分类
6. 长连接和短连接

https://www.cnblogs.com/gotodsp/p/6366163.html

===================================Cookie与Session==================================

 

1. cookie与session的作用与原理
2. 理解 Cookie
3. 理解 Session
4. Cookie 安全问题
5. 分布式 Session 框架
6. Cookie 压缩
7. 表单重复提交问题

网站中在很多地方都有表单重复提交问题，一种情况是用户在网速慢的情况下可能会重复提交表单，还有就是恶意用户通过程序来发送恶意请求，在这些情况下都要设计一个防止表单重复提交的机制。

要能够防止表单重复提交，就要标识用户的每一次访问请求，使得每一次访问对服务端来说都是唯一确定的。为了标识用户的每次访问请求，可以在用户请求一个表单域时增加一个隐藏表单项，这个表单项的值每次都是唯一的 token，如：

 <form id=”form” method=”post”>

     <input type=hidden name=“crsf_token” value=“xxxx”/>

 </form>

当用户在请求时生成这个唯一的 token，同时将这个 token 保存在用户的 Session 中，等用户提交请求时检查这个 token 和当前的 Session 中保存的 token 是否一致。如果一致，说明没有重复提交，否则用户提交上来的 token 已经不是当前的这个请求的合法 token。其工作过程如图 10-12 所示。

 

图 10-12.工作过程

 

图 10-12 是用户发起对表单页面的请求过程，生成唯一的 token 需要一个算法，最简单的就是可以根据一个种子作为 key 生成一个随机数，并保存在 Session 中，等下次用户提交表单时做验证。验证表单的过程如图 10-13 所示。

 

图 10-13.验证表单的过程

 

当用户提交表单时会将请求时生成的 token 带回来，这样就可以和 Session 中保存的 token 做对比，从而确认这次表单验证是否合法。

总结

Cookie 和 Session 都是为了保持用户访问的连续状态，之所以要保持这种状态，一方面是为了方便业务实现，另一方面就是简化服务端程序设计，提高访问性能，但是这也带来了另外一些挑战，如安全问题、应用的分布式部署带来的 Session 的同步问题及跨域名 Session 的同步等一系列问题。本章分析了 Cookie 和 Session 的工作原理，并介绍了一致分布式 Session 的解决方案。

1. 一次会话指的是：
2. 分布式session设置？分布式session一致性？
3. 分布式接口的幂等性设计（不能重复扣款）