1. OSI七层
物理层（传输比特流） 数据链路层（字节组合成帧） 网络层（ip层） 传输层（差错控制和流量控制）
会话层（管理会话） 表示层（数据压缩和加密） 应用层（为计算机用户提供应用接口和网络服务）
2. 三次握手过程，为什么是三次而不是两次
（1）三次握手过程：
第一次握手：建立连接时，客户端发送syn包（syn=x）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=y+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
（2）为什么是三次呢？
3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。这样就形成了死锁。
4. 四次挥手中的服务器端的ack应答与fin报文是否可以合并为一次发送给客户端 （ack报文和fin报文好像可以合并的，只要服务端已经没有数据需要传输）TCP第四次挥手客户端的状态
四次挥手的过程：
1）客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2）服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3）客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4）服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5）客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过2∗∗MSL（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6）服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。
5. TIME WAIT有什么用，TIME_WAIT出现在哪个阶段，并发量大的情况下TIME_WAIT同时大量存在有什么措施。大量time_wait会有什么问题，time_wait的时候能不能有别的客户端来请求服务器的服务。知道如何取消time-wait这个过程吗。
（1）虽然按道理，四个报文都发送完毕，我们可以直接进入CLOSE状态了，但是我们必须假象网络是不可靠的，有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复，但该ACK可能丢失。Server如果没有收到ACK，将不断重复发送FIN片段。所以Client不能立即关闭，它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器，等待2MSL的时间。如果在该时间内再次收到FIN，那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间，2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL，Client都没有再次收到FIN，那么Client推断ACK已经被成功接收，则结束TCP连接。
（2）TIME_WAIT出现在客户端收到服务端发送的结束连接请求FIN，并发出确认结束连接ACK之后，此时客户端不知道服务端是否收到结束确认报文，故进入TIME_WAIT阶段，防止成锁。
（3）并发量大的情况下 大量time_wait会有什么问题
① 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。
②在这个场景中，短连接表示“业务处理+传输数据的时间 远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念，比如，取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。（说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高）
综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。
（4）time_wait的时候能不能有别的客户端来请求服务器的服务。知道如何取消time-wait这个过程吗。
避免time-wait：
客户端，HTTP 请求的头部，connection 设置为 keep-alive，保持存活一段时间：现在的浏览器，一般都这么进行了
服务器端，
-
允许
time_wait状态的 socket 被重用 -
缩减
time_wait时间，设置为1 MSL（即，2 mins）
6. tcp 长连接短连接
短连接：我们模拟一下TCP短连接的情况，client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次读写就完成了，这时候双方任何一个都可以发起close操作，不过一般都是client先发起close操作。为什么呢，一般的server不会回复完client后立即关闭连接的，当然不排除有特殊的情况。从上面的描述看，短连接一般只会在client/server间传递一次读写操作
长连接：。Client与server完成一次读写之后，它们之间的连接并不会主动关闭，而是有一个保活功能，连接不会主动关闭，当客服端一定时间没有消息，则服务端进行探测，如果没有收到相应，则关闭连接。
7. 流量控制
流量控制，即通过控制发送方发送数据速度，让接收方来得及接受，防止数据丢失。主要通过滑动窗口实现。
8. 滑动窗口。滑动窗口已经发送序号为1、2、3的包，此时接收端发送ACK=4，问滑动窗口是否会移动？
9. 拥塞控制
网络中对某一资源的需求超过了该资源能提供的可用部分，网络就会变坏。
拥塞窗口：拥塞窗口减小，否则窗口增大，发送方把拥塞窗口作为发送窗口
网路拥塞的依据：没有按时收到应到达的确认报文
算法：
（1）慢开始：当拥塞窗口<=慢开始门限
拥塞窗口的值初始为1，慢开始门限也需要设置初始值，比如16，执行慢开始时，拥塞窗口值是几，就能发送几个报文段，接受方收到1后，发送方发2个数据报文段，确认后，发送方拥塞窗口值发送四个，当达到慢开始门限时，发送不再以指数增长，而是每次加1。
（2）拥塞避免：当拥塞窗口>=慢开始门限
当发送窗口值达到慢开始门限时，触发拥塞避免，发送不再以指数增长，而是每次加1，每次发送17 18 19等，当数据报文段在传输过程中丢失了几个，就会造成发送方对丢失报文的超时重传。发送方以此判断可能出现了拥塞，需要进行以下工作：
- 将慢开始门限值更新为发送拥塞时拥塞窗口值的一半
- 将拥塞窗口值减少为1，并重新开始执行慢开始算法
- 当达到慢开始门限时，转拥塞避免算法
个别报文段会在网络中丢失，但实际未发生拥塞， 降低传输效率，所以出现了快重传和快恢复
（3）快重传：发送方尽快进行重传，而不是等超时重传计时器超时再重传。如果报文段不是按顺序到达，则发送重复确认确实报文的上一个报文，发送方收到重复确认三次，则重新发送缺失报文段，
（4）快恢复：门限值和拥塞窗口值调整为当前窗口的一半，开始执行拥塞避免算法。
全过程：
10. TCP的拥塞控制和流量控制有什么区别
拥塞控制：防止过多的数据注bai入到du网络中，这样可以使网络中的路由器或链zhi路不致过载。拥塞控制所要做的dao都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
流量控制：指点对点通信量的控制，是端到端正的问题。流量控制所要做的就是抑制发送端发送数据的速率，以便使接收端来得及接收
简单来讲，流量控制是通信双方的问题，保证通信双方数据的有效传输，而拥塞控制是针对整个网络的，范围更广。
11. TCP/UDP的区别？既然UDP不可靠，那么如何让它可靠一些？UDP讲一下你的理解，什么情况下用UDP？
12. UDP丢包怎么办
（1）丢包的原因和解决办法：
- 接收端处理时间过长导致丢包：可以在接收端放一个缓存对列存起来
- 发送的包太大：可以切割成小包再发送
- 发送的包频率太快：sleep一下
13. http常见方法。http状态码。301和302的区别
（1）常见方法：
GET：从指定的资源中请求数据，可缓存
POST：将数据发送到服务器以创建或更新资源，它要求服务器确认请求中包含的内容作为由URI区分的Web资源的另一个下属。POST请求永远不会被缓存
PUT：将数据发送到服务器以创建或更新资源，它可以用上传的内容替换目标资源中的所有当前内容。它会将包含的元素放在所提供的URI下，如果URI指示的是当前资源，则会被改变。如果URI未指示当前资源，则服务器可以使用该URI创建资源。
DELETE：用来删除指定的资源，它会删除URI给出的目标资源的所有当前内容。
（2）状态码：
14. 301和302的区别
301表示旧地址A的资源已经被永久地移除了（这个资源不可访问了），搜索引擎在抓取新内容的同时也将旧的网址交换为重定向之后的网址；302表示旧地址A的资源还在（仍然可以访问），这个重定向只是临时地从旧地址A跳转到地址B，搜索引擎会抓取新的内容而保存旧的网址。
15. HTTPS的过程，密钥交换的过程，怎么验证证书是CA签名过的（你上面说的是基于RSA的交换过程，了解基于椭圆曲线的交换过程吗？）
-
客户端发送请求到服务端
-
服务端返回公钥和证书到客户端
-
客户端接收后会验证证书的安全性,如果通过则会随机生成一个随机数,用公钥对其加密,发送到服务端
-
服务端接受到这个加密后的随机数后会用私钥对其解密得到真正的随机数,随后用这个随机数当做私钥对需要发送的数据进行对称加密
-
客户端在接收到加密后的数据使用私钥(即生成的随机值)对数据进行解密并且解析数据呈现结果给客户
-
SSL加密建立
16. https每次都要走那些握手吗?浏览器呢?
17. 非对称加密的密钥是在客户端还是服务器端产生的吗？提示我由3部分组成
tcp header，TCP各种状态
ip header
cookie和session的区别
DNS的过程？最后请求到哪里了？用的是TCP还是UDP？