*1.描述下网页一个 Http 请求，到后端的整个请求过程:
https://blog.csdn.net/w372426096/article/details/82012229
浏览器输入https:www.koolearn.com这个URL，浏览器只知道名字是www.koolearn.com,但不知道具体的放完地址，名称只是方便记；首先使用“地址薄”协议DNS或精准的HTTPDNS查找，最终会找到IP地址，也就是互联网世界里的门牌号。知道地址，浏览器开始打包请求，使用Http协议或者加密传输Https协议。DNS，HTTP，HTTPS所在层都是应用层，通过socket变成传输下一层传输层。
传输层有TCP和UDP两种连接协议，传输层封装后，浏览器会将包交给操作系统的网络层。
网络层协议是IP协议（包含浏览器所在机器的 IP 地址和目标 IP 地址），操作系统知道目标IP地址，就可以找到目标机器；目标又分国内国外，国外通过网关；本地地址是mac地址。
操作系统将 IP 包交给了下一层，也就是MAC 层。网卡再将包发出，因为有mac地址所以能够到达网关。网关收到包后，会根据自己的判断能力进行下一步，网关往往是一个路由器，一层一关知道找到目标服务器
扩展：
当网络包到达一个城关的时候，可以通过路由表得到下一个城关的IP 地址，直接通过 IP 地址找就可以了，为什么还要通过
本地的 MAC 地址呢？
1.局域网内IP地址是动态分配的，假如我是192.168.2.100，如果我下线了，可能IP就分配给了另一台电脑。IP和设备并不总是对应的，这对通信就产生了问题，但是MAC地址不同，MAC地址和设备是一一对应且全球唯一的。所以局域网使用MAC地址通信没有问题。2.历史遗留问题：早期的以太网只有交换机，没有路由器，以太网内通过MAC地址通信。后来才有了互联网，为了兼容原本的模式，采用了IP+MAC地址通信的方式。为啥不推到了重来呢？看看IPv6的处境你就知道了。所以是先有MAC地址后有的IP，IP的提出主要还是因为MAC地址本身的缺陷，这个问题换成有了MAC为何还要IP地址也很有意思。3.我这里简单说一下第一：MAC地址本身的缺陷：因为MAC地址是硬件提供商写在网卡中的，MAC地址虽然唯一但是不能表明用户在整个互联网中的位置，除非维护一个超级大MAC地址对应表，那寻址效率肯定爆炸。但是IP地址解决了这个问题，因为IP地址是网络提供商给你的，所以你在哪里整个网络都是知道的。第二：安全问题：获取MAC地址是通过ARP协议来完成的，如果只用MAC地址通信，那么广播风暴是个难题。4.那么我觉得如果哪天每人一个固定的IPv6地址，那么我觉得MAC地址+IPv4的模式是不是可以被替换了？
2.有比较过 Http 和 RPC 吗？
1.rpc只是一种概念，实现rpc的方式有很多种，但本质上都需要客户端和服务端之间有一个通信协议，这个协议用于规范两个进程通过网络传输数据时数据的格式，一边按照协议把数据装配好通过网络传输，另一边按照协议把接收的二进制数据翻译成有用的数据，这个协议一定是两端商量好使用同一种的。也就是类似两个人交流，需要一个双方都懂的语言，一边说汉语一边说英语肯定是无法提供交流的，两边都说同一种话才能交流，一边通过语言的定义把他要表达的意图/想法转换成文字/发音提交给另一方，另一方通过语言的定义，在大脑中将文字翻译为真正要表达的东西。
2.并且协议是不可能没有的，比如就算你用Java的序列化方式来传输数据，那也是按Java序列化规范了数据格式，那也是一种两端都协定好的协议；亦或是你自己实现了某种传输的数据的格式，通信的两端都可以用你的规范下编写的编解码工具来处理/翻译数据，这也是一种协议。就好像原始人交流，通过呃呃啊啊几个简单音节配以手舞足蹈的动作，这种“语言”虽然简陋，但也实现了交流的目的，那他就是原始人的语言。
3.所以这个协议可以是soap协议，也可以是http协议，你不能说用http协议交流的远程过程调用就不算rpc了，用什么协议是服务端和客户端在开发时决定的，本质上是实现rpc，只是每个协议都有其自己的特性，不同的协议之间，会有一些比较大的区别，差异比较大的一个例子，比如说利用Json传输数据，翻译和构造都非常耗时，数据也很大，优点是开发人员友好，数据可读性强，调试方便，而使用Hession、protobuf，数据处理快，可读性差，优点就是快，但这个快体现在数据量小、处理快，和网络没有关系。
4.综上，RPC和HTTP根本不是一个层面的东西
最后，我看了上面的回答，有好几个问题不明白，有的人把http协议和tcp协议并列起来谈，这两个不是一个上一个下吗，没有tcp协议，哪来的http协议？有的说“自定义tcp协议”，是表达错误吗？是想说“基于tcp协议传输的自定义协议”吗？有的说HTTP开销在连接的建立与断开上，难道其他RPC协议不走TCP吗？HTTP也是可以实现长连接的吧，再不济，抛去第三方的实现，自己实现一个基于HTTP协议的通信工具，每次交互忽视HTTP头关于连接的部分，永远是长连接，只是把HTTP协议作为数据交流的协议不也OK吗。
良好的rpc调用是面向服务的封装，针对服务的可用性和效率等都做了优化。单纯使用http调用则缺少了这些特性。
https://www.jianshu.com/p/5b90a4e70783
3.HttpClient 你说说里面的具体实现吧？（涉及了哪些东西）
https://blog.csdn.net/w372426096/article/details/82713315
4.那要你设计一个高性能的 Http ，你会怎么设计？（后续再补充）
【高性能HTTP应用的策略】
所以，当我们需要一个高性能的HTTP接口型应用时：
1、服务器端：关闭KeepAlive。
2、服务器端：最好直接支持HTTP协议（注意用POST，不要GET）,而不是任何包装过的协议，比如：hessian/soap等。
3、服务器端：在一个请求中，最好设计成：支持多条指令批处理，以节省连接数。
4、服务器端：对请求的处理应当尽可能的快（如在150ms内）。
5、客户端：在代码中，同一个客户端实例中全部请求结束后应主动关闭连接（无须事先设置客户端的ConnectionTimeOut参数）。
6、客户端：如服务器未关闭KeepAlive，在同一个客户端实例中可以适量发出多个请求（总时间应稍小于服务器KeepAliveTimeout参数）。此方式需要精确操作，不推荐。
最后，在接口设计上，对于一些异步操作，尽量不要设计成单方面轮询模式（减少大量无谓请求数），应设计成被调用方的异步结果回调模式。
【一些优化细节】
在服务器端，我们一般选用的是Apache+Tomcat/JBoss的组合。关于JBoss的配置及优化可参看JBoss官网。
最主要的是关于Apache的优化，推荐阅读两篇文章：
1、Apache性能优化：http://www.aliwo.net:8080/2009/12/apache/
2、Apache中KeepAlive配置的合理使用：http://www.net527.cn/a/caozuoxitong/Linux/5283.html
在客户端的Java代码中，我们最常使用的是HttpClient工具包。
有一些细节要注意：
1、在每一个HttpClient实例发完请求后，（如不再使用）应及时关闭连接。
最简单的方式是，在HTTP Request Header中发送(Connection: close)，指示服务器关闭当前连接。
代码如下：
method.setRequestHeader("Connection", "close");
2、可以设计为单例模式：无需每次创建HttpClient实例，可多次发送请求
参考：http://seanhe.iteye.com/blog/234759
5.TCP 和 UDP 的区别？TCP 数据传输过程中怎么做到可靠的？
传输层有两个性质不同的协议：TCP（Transmission ControlProtocol，传输控制协议）和 UDP（User Data Protocol，⽤户数据报协
议）。
TCP与UDP区别总结：
1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道
UDP实现可靠传输：
由于在传输层UDP已经是不可靠的连接，那就要在应用层自己实现一些保障可靠传输的机制
简单来讲，要使用UDP来构建可靠的面向连接的数据传输，就要实现类似于TCP协议的
超时重传（定时器）
有序接受 （添加包序号）
应答确认 （Seq/Ack应答机制）
滑动窗口流量控制等机制 （滑动窗口协议）
等于说要在传输层的上一层（或者直接在应用层）实现TCP协议的可靠数据传输机制，比如使用UDP数据包+序列号，UDP数据包+时间戳等方法。
目前已经有一些实现UDP可靠传输的机制，比如UDT
TCP 实现可靠传输
通过三次握手连接，四次挥手断开的机制
6.三次握手和四次挥手、为什么挥手需要四次
https://blog.csdn.net/w372426096/article/details/81836919
7.http 默认端口，https 默认端口
HTTP协议代理服务器常用端口号：80/8080/3128/8081/9098
HTTPS（securely transferring web pages）服务器，默认端口号为443/tcp 443/udp
TOMCAT，默认端口号为8080
8.DNS 你知道是干嘛的吗？
DNS域名系统：解析域名，每个ip地址都可以有一个主机名，主机名由一个或多个字符串组成，字符串之间用小数点隔开。有了主机名，就不要死记硬背每台IP设备的IP地址，只要记住相对直观有意义的主机名就行了。这就是DNS协议的功能。
9.计算机网络七层模型。
10.什么是长连接和短连接
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加入这行代码：
Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。
http://blog.jobbole.com/104108/
11.Http1.0和2.0相比有什么区别，可参考《Http 2.0》
https://blog.csdn.net/w372426096/article/details/81282071
12.Https的基本概念
HTTPS (基于安全套接字层的超文本传输协议 或者是 HTTP over SSL) 是一个 Netscape 开发的 Web 协议。
可以说：HTTPS = HTTP + SSL；HTTPS 在 HTTP 应用层的基础上使用安全套接字层作为子层。
超文本传输协议 (HTTP) 是一个用来通过互联网传输和接收信息的协议。HTTP 使用请求/响应的过程，因此信息可在服务器间快速、轻松而且精确的进行传输。当你访问 Web 页面的时候你就是在使用 HTTP 协议，但 HTTP 是不安全的，可以轻松窃听你跟 Web 服务器之间的数据传输。在很多情况下，客户和服务器之间传输的是敏感信息，需要防止未经授权的访问。为了满足这个要求，网景公司(Netscape)推出了 HTTPS，也就是基于安全套接字层的 HTTP 协议。
大多数情况下，HTTP 和 HTTPS 是相同的，因为都是采用同一个基础的协议，作为 HTTP 或 HTTPS 客户端——浏览器，设立一个连接到 Web 服务器指定的端口。当服务器接收到请求，它会返回一个状态码以及消息，这个回应可能是请求信息或者指示某个错误发送的错误信息。系统使用统一资源定位器 URI 模式，因此资源可以被唯一指定。而 HTTPS 和 HTTP 唯一不同的只是一个协议头(https)的说明，其他都是一样的。
1. HTTP 的 URL 以 http:// 开头，而 HTTPS 的 URL 以 https:// 开头
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 标准端口是 80 ，而 HTTPS 的标准端口是 443
4. 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 工作在传输层
5. HTTP 无需加密，而 HTTPS 对传输的数据进行加密
6. HTTP 无需证书，而 HTTPS 需要认证证书
使用 HTTPS 连接时，服务器要求有公钥和签名的证书。
当使用 https 连接，服务器响应初始连接，并提供它所支持的加密方法。作为回应，客户端选择一个连接方法，并且客户端和服务器端交换证书验证彼此身份。完成之后，在确保使用相同密钥的情况下传输加密信息，然后关闭连接。为了提供 https 连接支持，服务器必须有一个公钥证书，该证书包含经过证书机构认证的密钥信息，大部分证书都是通过第三方机构授权的，以保证证书是安全的。
换句话说，HTTPS 跟 HTTP 一样，只不过增加了 SSL。
HTTP 包含如下动作：
1. 浏览器打开一个 TCP 连接
2. 浏览器发送 HTTP 请求到服务器端
3. 服务器发送 HTTP 回应信息到浏览器
4. TCP 连接关闭
SSL 包含如下动作：
1. 验证服务器端
2. 允许客户端和服务器端选择加密算法和密码，确保双方都支持
3. 验证客户端(可选)
4. 使用公钥加密技术来生成共享加密数据
5. 创建一个加密的 SSL 连接
6. 基于该 SSL 连接传递 HTTP 请求
银行网站、支付网关、购物网站、登录页、电子邮件以及一些企业部门的网站应该使用 HTTPS，例如：
13.http协议格式，get和post的区别
| GET | POST | |
|---|---|---|
| 后退按钮/刷新 | 无害 | 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。 |
| 书签 | 可收藏为书签 | 不可收藏为书签 |
| 缓存 | 能被缓存 | 不能缓存 |
| 编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded 或 multipart/form-data。为二进制数据使用多重编码。 |
| 历史 | 参数保留在浏览器历史中。 | 参数不会保存在浏览器历史中。 |
| 对数据长度的限制 | 是的。当发送数据时，GET 方法向 URL 添加数据；URL 的长度是受限制的（URL 的最大长度是 2048 个字符）。 | 无限制。 |
| 对数据类型的限制 | 只允许 ASCII 字符。 | 没有限制。也允许二进制数据。 |
| 安全性 | 与 POST 相比，GET 的安全性较差，因为所发送的数据是 URL 的一部分。 在发送密码或其他敏感信息时绝不要使用 GET ！ |
POST 比 GET 更安全，因为参数不会被保存在浏览器历史或 web 服务器日志中。 |
| 可见性 | 数据在 URL 中对所有人都是可见的。 | 数据不会显示在 URL 中。 |
1. GET提交的数据会放在URL之后，以?分割URL和传输数据，参数之间以&相连，如EditPosts.aspx?name=test1&id=123456.POST方法是把提交的数据放在HTTP包的Body中.
2. GET方式需要使用Request.QueryString来取得变量的值，而POST方式通过Request.Form来获取变量的值。