1.OSI参考模型和TCP/IP模型
OSI参考模型是ISO组织指定的网络互联的一个参考模型，总共分为七层，分别是：应用层、表示层、会话层、传输层、网络层、数据链路层、物理层。
TCP/IP是现在通用的网络互联模型，总共五层，分别是：应用层(FTP、HTTP、DNS)、传输层(TCP、UDP)、网络层（ARP、ICMP）、数据链路层、物理层。
2.TCP和UDP，以及两者的区别
TCP：
TCP是面向连接的传输层协议，提供可靠交付。
UDP：
UDP是面向无连接的传输层协议，提供尽最大努力交付。
TCP和UDP的区别：
--TCP面向连接，UDP面向非连接
--TCP提供可靠交付（确认重传机制），UDP是尽最大努力交付，不保证可靠交付
--TCP报文头复杂，冗余信息多，而UDP报文头简单，额外开销小
--TCP速度较慢，而UDP速度受限于数据生成速度，传输速度，速度较快
--TCP通过MTU对报文进行拆分合并，UDP不进行拆分合并
3.TCP三次握手和四次挥手
TCP通过三次握手来建立连接：
第一次握手：建立连接时，客户端发送SYN包（序列号seq=j）到服务器，并进入SYN_SEND状态，等待服务器确认
第二次握手：服务器收到syn包,必须确认客户的SYN（确认应答号ack=j+1）,同时自己也发送一个SYN包（序列号seq=k）,即SYN+ACK包,此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包,向服务器发送确认包ACK(确认应答号ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手.
为什么需要三次握手来建立连接：
为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值 的必经步骤。如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。
TCP断开连接需要四次挥手：
客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送。
服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。和SYN一样，一个FIN将占用一个序号。
服务器B关闭与客户端A的连接，发送一个FIN给客户端A。
客户端A发回ACK报文确认，并将确认序号设置为收到序号加1。
TCP断开连接为什么需要四次挥手：
因为TCP是全双工的，连接的两端都可以发送/接收数据，所以关闭连接时两方需要FIN（请求断开）和ACK（确认）。
tcp挥手为什么等待2ms
TCP断开连接时，首先发起断开请求的一方在受到对方的FIN包，发送ACK包后需要等待一段时间，是为了保证对方收到ACK(超时可以重传)，以及避免新旧连接混淆。
1、防止客户端最后一次发给服务器的确认在网络中丢失以至于客户端关闭，而服务端并未关闭，导致资源的浪费。
2、等待最大的2msl可以让本次连接的所有的网络包在链路上消失，以防造成不必要的干扰。
4.HTTP和HTTPS
HTTP请求包和响应包：
HTTP请求报文：
方法 URL 协议版本
请求头部字段名：值
...
请求正文
HTTP响应报文：
协议版本 状态码 描述
响应头部字段名：值
...
响应正文
GET请求和POST请求的区别：
GET请求数据放在URL中(以？分割URL和传输的数据，参数之间以&相连)，而POST请求则放在报文体中
GET请求提交的url中的数据最多只能是1024字节，这个限制是浏览器或者服务器给添加的，http协议并没有对url长度进行限制，目的是为了保证服务器和浏览器能够正常运行，防止有人恶意发送请求。
POST请求则没有大小限制。
GET请求符合幂等性和安全性，POST请求不符合
GET请求可以被缓存、存储，POST请求不可以
状态码和重定向 Http code 问：501到505解释下，403的每种情况呢？
1XX:接收的请求正在处理
2XX:成功
3XX:重定向
4XX:客户端错误
5XX:服务器错误
https原理，ssl/tls https的加密过程 对称、非对称加密，为什么传输的时候要用对称加密
对称加密：对称加密又叫做私钥加密，即信息的发送方和接收方使用同一个密钥去加密和解密数据
HTTPS在传输的过程中会涉及到三个密钥：
服务器端的公钥和私钥，用来进行非对称加密
客户端生成的随机密钥，用来进行对称加密
一个HTTPS请求实际上包含了两次HTTP传输，可以细分为8步。
1.客户端向服务器发起HTTPS请求，连接到服务器的443端口
2.服务器端有一个密钥对，即公钥和私钥，是用来进行非对称加密使用的，服务器端保存着私钥，不能将其泄露，公钥可以发送给任何人。
3.服务器将自己的公钥发送给客户端。
4.客户端收到服务器端的公钥之后，会对公钥进行检查，验证其合法性，如果发现发现公钥有问题，那么HTTPS传输就无法继续。严格的说，这里应该是验证服务器发送的数字证书的合法性，关于客户端如何验证数字证书的合法性，下文会进行说明。如果公钥合格，那么客户端会生成一个随机值，这个随机值就是用于进行对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，这样在概念上和服务器端的密钥容易进行区分。然后用服务器的公钥对客户端密钥进行非对称加密，这样客户端密钥就变成密文了，至此，HTTPS中的第一次HTTP请求结束。
5.客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端密钥发送给服务器。
6.服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
7.然后服务器将加密后的密文发送给客户端。
8.客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成。
http和https的区别：
https协议需要到ca申请证书，一般免费证书很少，需要交费。
http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。
http和https使用的是完全不同的连接方式用的端口也不一样，前者是80，后者是443。
http的连接很简单，是无状态的。
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全。
session和cookie：
HTTP是无连接的协议，服务器可以利用cookie和session来识别用户的身份。具体来说cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案。而由于采用服务气短保持状态的方案在客户端也需要保存一个标识，所以session机制可能需要借助于cookie机制来达到保存目的。
cookie机制：服务器通过在HTTP响应头中加入一行特殊的指示让浏览器生成响应的cookie（浏览器通过脚本也可以自动生成）。cookie的使用是由浏览器按照一定的原则在后台自动发给服务器。若cookie的作用范围包含请求资源的地址，则就将该cookie附在请求头上发给服务器。
session机制：当服务器程序需要为某个客户端的请求创建一个session时，服务器首先检查这个客户端的请求里是否已包含了一个session标识（称为session id），如果已包含则说明以前已经为此客户端创建过session，服务器就按照session id把这个session检索出来使用（检索不到，会新建一个），如果客户端请求不包含session id，则为此客户端创建一个session并且生成一个与此session相关联的session id，session id的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个session id将被在本次响应中返回给客户端保存。
保存session_id的方式：保存这个session id的方式可以采用cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器。还有经常被使用的一种技术叫做URL重写，就是把session id直接附加在URL路径的后面。
cookie和session实现用户登录过程 登陆状态如何保持?
当用户请求页面，一般需要先登录，用户第一次输入用户名和密码之后，前台发送post请求，后台获取用户信息，通过查询数据库来验证用户信息是否正确，如果验证通过，则会开辟一块session空间来储存用户数据，并且同时生成一个cookie字符串，由后台返回给前台，前台接收后，会把这个cookie字符串储存到浏览器的cookie空间中，这个cookie就相当于一把钥匙，可以打开后台存储对应用户信息的锁，当用户下一次请求的时候，客户端便会自动携带这个cookie去请求服务器，服务器识别后，就会读取session中的用户信息，这样用户就可以直接访问，就不需要再输入用户名密码来验证身份了。
session和cookie的区别：
存储位置不同：Cookie数据信息存储在客户端浏览器上，session存放在服务器上
隐私策略不同：cookie对用户可见，其他人可以获得cookie后进行cookie欺骗，所以不安全；session存放在服务器上，对客户端透明，不存在敏感信息泄露的风险
服务器压力不同：cookie存放在浏览器，不占用服务器资源；session保管在服务器，每个用户都会产生一个session，高并发会耗费大量资源
有效期不同：cookie可以长期保存；session只要关闭窗口就会失效
大小不同：单个cookie保存的数据不能超过4k，很多浏览器限制一个站点最对保存20个cookie；而session没有类似限制，取决于服务器
session共享问题 session共享有多少种实现方式
session共享问题：用户在Tomcat1上登录，此时系统会在Tomcat1上记录用户的session信息；然而当下一次用户请求由于nginx负载均衡交给了Tomcat2处理，此时Tomcat2并没有该用户的session信息，会要求用户重新登录。
session同步：动态的将某个tomcat下的session复制到其他tomcat中。
将信息放在cookie-放在客户端：状态信息不再保存在服务端，而是保存在客户端，客户端每次访问服务器的时候，把这个信息带给服务器。
终极解决方案-新SSO单点登录：将session从系统中独立出来
5.浏览器键入URL,会发生什么，用到哪些协议
通过DNS解析，获取IP地址（本地host文件，本地DNS服务器，...） DNS协议
客户端和服务端建立TCP连接(三次握手) TCP协议 IP协议
客户端发起HTTP请求(请求报文) HTTP协议
服务端响应客户端发起的HTTP请求(响应报文)
关闭TCP连接(四次挥手)
浏览器解析数据，显示