七层模型

应用层：用户接口、应用程序

表示层：数据表示、压缩和加密

会话层：会话的建立和结束

传输层：端到端控制

网络层：路由、寻找

数据链路层：保证无差错的忽略链路的data link

物理层：传输比特流

TCP和UDP的区别

TCP（传输控制协议）：面向连接，提供可靠的数据传输，用于传输大量数据，使用数据流模式，速度慢，建立连接是开销较大。

UDP（用户数据协议）：非面向连接，传输不可靠，用于传输少量的数据，速度快。

UDP可以实现一对多？？

HTTP、HTTPS

1、HTTP是超文本传输协议，信息是明文传输，HTTPS是具有安全性的SSL加密传输协议。

2、HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

3、HTTP连接简单，无状态；HTTPS协议是由HTTP+SSL协议构成的可进行加密传输、身份认证的网络协议。

HTTP为什么底层是TCP不是UDP ?

TCP是基于流式传输的，怎么设计协议，进行协议的解析？

TCP为什么是三次握手和四次挥手？

TCP三次握手：

        1、由客户端发送一个叫做SYN（SYN=J）包到服务器，并进入SYN_SEND状态，然后等待服务器响应。

        2、服务器接收到SYN包，必须确定客户端的SYN（ACK=J+1），同时也发送一个SYN（SYN=K）包，也就是SYN+ACK，进入SYM_RECV状态 。

        3、接收到服务器发来的SYN+ACK包，并向服务器发送确认包ACK(ACK=K+1)，发完之后，客户端和服务器进入ESTABLISHED状态，完成三次握手

TCP四次挥手（客户端关闭）：

        1、客户端发送一个FIN的报文给服务器之后，进入等待服务器的响应

        2、服务器收到FIN后，并确认是由客户端发起的，同时也会发送一条ACK=X+1的报文

        3、等到客户端接收到ACK报文之后，服务器关闭了与客户端的连接，会发送一个FIN报文给客户端

    4、客户端收到由服务器发送的FIN报文后，就会关闭与服务器的连接，并且发送ACK给服务器

为啥是三次握手，四次挥手？

        1、连接时，服务端收到了客户端的SYN连接请求的报文之后，可以直接发送SYN+ACK报文，其中ACK报文是用来响应，SYN报文是用来同步的。

        2、关闭时，服务端收到FIN报文后，很可能并不会马上就关闭Socket连接，所以只能先回复一个ACK报文，告诉客户端，你发的FIN报文我收到了，只有等到服务器的所有报文发送完了，服务器才会发送FIN报文，所以才需要四次挥手。

TCP是如何保证可靠的？

拥塞控制

TCP 的拥塞控制主要是四个算法：慢启动、拥塞避免、拥塞发生、快速恢复。

慢启动算法：

        慢启动的算法如下(cwnd 全称 Congestion Window)：

                1、连接建好的开始先初始化 cwnd = 1，表明可以传一个 MSS（Max Segment Size）大小的数据。

                2、每当收到一个 ACK，cwnd++; 呈线性上升。

                3、每当过了一个 RTT，cwnd = cwnd*2; 呈指数上升。

                4、还有一个 ssthresh（slow start threshold），是一个上限，当 cwnd >= ssthresh时，就会进入「拥塞避免算法」。

拥塞避免算法：

        前面说过，还有一个 ssthresh（slow start threshold），是一个上限，当 cwnd >= ssthresh 时，就会进入拥塞避免算法。一般来说 ssthresh 的值是 65535 字节，当 cwnd 达到这个值时后，算法如下：

                1、收到一个 ACK 时，cwnd = cwnd + 1/cwnd。

                2、当每过一个 RTT 时，cwnd = cwnd + 1。

        这样就可以避免增长过快导致网络拥塞，慢慢的增加调整到网络的最佳值。很明显，是一个线性上升的算法。

拥塞状态时的算法：

当丢包的时候，会有两种情况：

        1、等到 RTO 超时，重传数据包。TCP 认为这种情况太糟糕，反应也很强烈。

                    sshthresh = cwnd/2。

                    cwnd 重置为 1。

                    进入慢启动过程。

        2、快速重传（Fast Retransmit）算法，也就是在收到 3 个 duplicate ACK 时就开启重传，而不用等到 RTO 超时。

                    TCP Tahoe 的实现和 RTO 超时一样。

                    TCP Reno的实现是：

                            cwnd = cwnd/2。

                            sshthresh = cwnd。

                            进入快速恢复算法（Fast Recovery）。

上面我们可以看到 RTO 超时后，sshthresh 会变成 cwnd 的一半，这意味着，如果 cwnd<=sshthresh 时出现的丢包，那么 TCP 的 sshthresh 就会减了一半，然后等 cwnd 又很快地以指数级增涨爬到这个地方时，就会成慢慢的线性增涨。我们可以看到，TCP 是怎么通过这种强烈地震荡快速而小心得找到网站流量的平衡点的。  

快速恢复算法：

        TCP Reno 这个算法定义在 RFC5681。快速重传和快速恢复算法一般同时使用。快速恢复算法是认为，你还有 3 个 Duplicated Acks 说明网络也不那么糟糕，所以没有必要像 RTO 超时那么强烈。注意，正如前面所说，进入 Fast Recovery 之前，cwnd 和 sshthresh 已被更新：  

                cwnd = cwnd /2。

                sshthresh = cwnd。

        然后，真正的 Fast Recovery 算法如下：

                cwnd = sshthresh + 3 * MSS （3 的意思是确认有 3 个数据包被收到了）。

                重传 Duplicated ACKs 指定的数据包。

                如果再收到 duplicated ACKs，那么 cwnd = cwnd + 1。

                如果收到了新的 ACK，那么 cwnd = sshthresh，然后就进入了拥塞避免的算法了。

为什么要使用HTTP？为什么不直接用TCP？

如何保证HTTP传输到达？

HTTP头部有哪些内容？

TCP头部多长，IP呢

HTTP有哪些部分

HTTP协议GET、 POST的区别

HTTP超文本传输协议，是短连接，是客户端主动发送请求，服务器做出响应，服务器响应之后，链接断开。HTTP是一个属于应用层面向对象的协议，HTTP有两类报文：请求报文和响应报文。

HTTP请求报文：一个HTTP请求报文由请求行、请求头部、空行和请求数据4部分组成。

HTTP响应报文：由三部分组成：状态行、消息报头、响应正文。

区别：

        1、GET请求：参数在地址后拼接，没有请求数据，不安全（因为所有参数都拼接在地址后面），不适合传输大量数据（长度有限制，为1024个字节）。

                GET提交、请求的数据会附在URL之后，即把数据放置在HTTP协议头<requestline>中。以分割URL和传输数据，多个参数用&连接。如果数据是英文字母或数字，原样发送，如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用BASE64加密。

            POST请求：参数在请求数据区放着，相对GET请求更安全，并且数据大小没有限制。把提交的数据放置在HTTP包的包体<request-body>中。

        2、GET提交的数据会在地址栏显示出来，而POST提交，地址栏不会改变。

        GET提交时，传输数据就会受到URL长度限制，POST由于不是通过URL传值，理论上书不受限。

        POST的安全性要比GET的安全性高；

        通过GET提交数据，用户名和密码将明文出现在URL上，比如登陆界面有可能被浏览器缓存。

HTTPS：安全超文本传输协议（Secure Hypertext Transfer Protocol），它是一个安全通信通道，基于HTTP开发，用于客户计算机和服务器之间交换信息，使用安全套结字层（SSI）进行信息交换，即HTTP的安全版。

HTTP请求的哪些方法用过？什么时候选择GET、POST、PUT？

HTTP中的同步和异步

Http协议30x的错误是什么

Ping是什么协议

Http2.0如1.x的区别？

HTTP1.0：客户端的每次请求都要建立一次单独的连接，在处理完本次请求后，就自动释放连接

HTTP1.1：可以在一次连接中处理多个请求，并且多个请求可以叠加进行，不需要等待一次请求结束后再发送下一个请求

HTTP2.0：兼容HTTP1.1（貌似是优化版本，提高了Web性能）

Cookie

因为 Http 无状态的特性，如果需要判断是哪个用户，这时就需要 Cookie 和 Session。

Cookie 存储在客户端，用来记录用户状态，区分用户。一般都是服务端把生成的 Cookie 通过响应返回给客户端，客户端保存。

Session 存储在网络端，需要依赖 Cookie 机制。服务端生成了 Session 后，返回给客户端，客户端 setCookie:sessionID，所以下次请求的时候，客户端把 Cookie 发送给服务端，服务端解析出 SessionID，在服务端根据 SessionID 判断当前的用户。  

修改 ：

        1、相同 Key 值得新的 Cookie 会覆盖旧的 Cookie。

        2、覆盖规则是 name path 和 domain 等需要与原有的一致。

删除：

        1、相同 Key 值得新的 Cookie 会覆盖旧的 Cookie。

        2、覆盖规则是 name path 和 domain 等需要与原有的一致。

        3、设置 Cookie 的 expires 为过去的一个时间点，或者 maxAge = 0。

如何保证 Cookie 的安全？

1、对 Cookie 进行加密处理。

2、只在 Https 上携带 Cookie。

3、设置 Cookie 为 httpOnly，防止跨站脚本攻击。

NSCache

自己设计一个缓存器

怎么实现LRU

MTU？

发送一个HTTP请求的过程

socket异常断开时，设计一个合理的重连机制。

断点续传怎么实现？需要设置什么？

断点续传可以分为两部分：一部分是断点，一部分是续传。断点续传实质就是能记录上一次已下载完成的位置。

1、断点续传需要在下载过程中记录每条线程的下载进度。

2、每次下载开始之前先读取数据库，查询是否有未完成的记录，有就继续下载，没有则创建新记录插入数据库。

3、在每次向文件中写入数据之后，在数据库中更新下载进度。

4、下载完成之后删除数据库中下载记录。

描述下IM系统如何保证消息不丢

IM数据库如何设计表

抓包工具抓取HTTPS的原理