Java面试题冲刺第六天--网络编程1
面试题1：说一下tcp连接的三次握手和四次挥手吧
正经回答：
握手：tcp连接
挥手：tcp断开
三次握手：
首先，三次握手的本质是确认通信双方（client端、server端）收发数据的能力；
三次握手其实就是指：建立一个tcp连接时，需要客户端和服务器总共发送3个包，通过这三个请求包，来确认双方（client、server）的接收能力和发送能力是否正常，同时，指定自己的初始化序列号为后面的可靠性传送做准备。实质上就是连接服务器指定端口，建立tcp连接，并同步连接双方的序列号和确认号，交换tcp窗口大小信息。
注：刚开始客户端处于 closed 的状态，服务端处于 listen 状态。
三次握手（连接）流程白话文介绍：
我和女朋友养了一只信鸽来传信，今天我要试一试好不好使，不好使晚上我就准备吃烧烤。
-
第一次握手：我把信（第一封信）绑在鸽子腿上发给女朋友，如果女朋友收到了，就确定了我的发件能力和她的收件能力没问题； -
第二次握手：然后女朋友给我回信（第二封信），我如果收到了，说明我的收件能力和她的发件能力没问题； -
第三次握手：然而此时女朋友还不知道她的发件能力和我的收件能力是否正常；因此我还要给他发（第三封信）说明，收到后最终决定晚上去吃烤鱼。信鸽：卧槽，真tm累，你们手机都是假的吧。
三次握手理论流程：
-
第一次握手：客户端将标志位syn置为1，随机产生一个值seq=j，并将该数据包发送给服务器端，客户端进入syn_sent状态，等待服务器端确认。 -
第二次握手：服务器端收到数据包后由标志位syn=1知道客户端请求建立连接，服务器端将标志位syn和ack都置为1，ack=j+1，随机产生一个值seq=k，并将该数据包发送给客户端以确认连接请求，服务器端进入syn_rcvd状态。 -
第三次握手：客户端收到确认后，检查ack是否为j+1，ack是否为1，如果正确则将标志位ack置为1，ack=k+1，并将该数据包发送给服务器端，服务器端检查ack是否为k+1，ack是否为1，如果正确则连接建立成功，客户端和服务器端进入established状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。
四次挥手：
四次挥手即终止tcp连接，就是指断开一个tcp连接时，需要客户端和服务端总共发送4个包以确认连接的断开。在socket编程中，这一过程由客户端或服务端任一方执行close来触发。
由于tcp连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原则是当一方完成数据发送任务后，发送一个fin来终止这一方向的连接，收到一个fin只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这个tcp连接上仍然能够发送数据，直到这一方向也发送了fin。首先进行关闭的一方将执行主动关闭，而另一方则执行被动关闭。
四次挥手理论流程
中断连接端可以是客户端，也可以是服务器端。
第一次挥手：客户端发送一个fin=m，用来关闭客户端到服务器端的数据传送，客户端进入fin_wait_1状态。意思是说"我客户端没有数据要发给你了"，但是如果你服务器端还有数据没有发送完成，则不必急着关闭连接，可以继续发送数据。
第二次挥手：服务器端收到fin后，先发送ack=m+1，告诉客户端，你的请求我收到了，但是我还没准备好，请继续你等我的消息。这个时候客户端就进入fin_wait_2 状态，继续等待服务器端的fin报文。
第三次挥手：当服务器端确定数据已发送完成，则向客户端发送fin=n报文，告诉客户端，好了，我这边数据发完了，准备好关闭连接了。服务器端进入last_ack状态。
第四次挥手：客户端收到fin=n报文后，就知道可以关闭连接了，但是他还是不相信网络，怕服务器端不知道要关闭，所以发送ack=n+1后进入time_wait状态，如果server端没有收到ack则可以重传。服务器端收到ack后，就知道可以断开连接了。客户端等待了2msl后依然没有收到回复，则证明服务器端已正常关闭，那好，我客户端也可以关闭连接了。最终完成了四次握手。
深入追问：
追问1：为什么连接的时候是三次握手，关闭的时候却是四次握手？
因为当server端收到client端的syn连接请求报文后，可以直接发送syn+ack报文。其中ack报文是用来应答的，syn报文是用来同步的。但是关闭连接时，当server端收到fin报文时，很可能并不会立即关闭socket，所以只能先回复一个ack报文，告诉client端，“你发的fin报文我收到了”。只有等到我server端所有的报文都发送完了，我才能发送fin报文，因此不能一起发送。故需要四步握手。
追问2：如果已经建立了连接，但是客户端突然出现故障了怎么办？
tcp还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。
若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
面试题2：常见的http状态码有哪些？
正经回答：
http状态码表示客户端http请求的返回结果、标识服务器处理是否正常、表明请求出现的错误等。
状态码的类别：
| 状态码 | 原因 |
|---|---|
| 1xx | informational（信息性状态码） 接受的请求正在处理 |
| 2xx | success（成功状态码） 请求正常处理完毕 |
| 3xx | redirection（重定向状态码） 需要进行附加操作以完成请求 |
| 4xx | client error（客户端错误状态码） 服务器无法处理请求 |
| 5xx | server error（服务器错误状态码） 服务器处理请求出错 |
| 状态码 | 原因 |
|---|---|
| 2xx | 成功（这系列表明请求被正常处理了） |
| 200 | ok，表示从客户端发来的请求在服务器端被正确处理 |
| 204 | no content，表示请求成功，但响应报文不含实体的主体部分 |
| 206 | partial content，进行范围请求成功 |
| 状态码 | 原因 |
|---|---|
| 3xx | 重定向（表明浏览器要执行特殊处理） |
| 301 | moved permanently，永久性重定向，表示资源已被分配了新的 url |
| 302 | found，临时性重定向，表示资源临时被分配了新的 url |
| 303 | see other，表示资源存在着另一个 url，应使用 get 方法获取资源 |
| 304 | not modified，表示服务器允许访问资源，但请求未满足条件的情况（与重定向无关） |
| 307 | temporary redirect，临时重定向，和302含义类似，但是期望客户端保持请求方法不变向新的地址发出请求 |
| 状态码 | 原因 |
|---|---|
| 4xx | 客户端错误 |
| 400 | bad request，请求报文存在语法错误 |
| 401 | unauthorized，表示发送的请求需要有通过 http 认证的认证信息 |
| 403 | forbidden，表示对请求资源的访问被服务器拒绝，可在实体主体部分返回原因描述 |
| 404 | not found，表示在服务器上没有找到请求的资源 |
| 状态码 | 原因 |
|---|---|
| 5xx | 服务器错误 |
| 500 | internal sever error，表示服务器端在执行请求时发生了错误 |
| 501 | not implemented，表示服务器不支持当前请求所需要的某个功能 |
| 503 | service unavailable，表明服务器暂时处于超负载或正在停机维护，无法处理请求 |
面试题3：先说说get和post请求有哪些区别吧？
正经回答：
get请求在url中传送的参数是有长度限制的，而post没有。
get比post更不安全，因为参数直接暴露在url上，所以不能用来传递敏感信息。而post数据不会显示在url中。是放在request body中。
对参数的数据类型，get只接受ascii字符，而post没有限制。
get请求参数会被完整保留在浏览器历史记录里；相反，post请求参数也不会被浏览器保留。
get请求只能进行url编码（application/x-www-form-urlencoded），而post支持多种编码方式。
get请求会被浏览器主动缓存，而post不会，除非手动设置。
get在浏览器回退时是无害的，而post会再次提交请求。
深入追问：
追问1：那get请求有request body么？如果有的话参数可以像post请求一样放在里面么？
其实吧，get和post在本质上没有区别，都是http协议中的两种发送请求的方法。而http呢，是基于tcp/ip的关于数据如何在万维网中如何通信的协议。
万维网：简称www，是world wide web的简称，也称为web、3w等
http的底层是tcp/ip。所以get和post的底层也是tcp/ip，也就是说，get/post都是tcp链接。
get和post能做的事情是一样一样的。你要给get加上request body，给post带上url参数，技术上是完全行的通的。
- 举个例子吧：
tcp就像汽车，我们用tcp来运输数据，它很可靠，从来不会发生丢件少件的现象。
但是如果路上跑的全是看起来一模一样的汽车，那这个世界看起来是一团混乱，送急件的汽车可能被前面满载货物的汽车拦堵在路上，整个交通系统一定会瘫痪。
为了避免这种情况发生，交通规则http诞生了。http给汽车运输设定了好几个服务类别，包括get, post, put等等，
http规定，当执行get请求的时候，要给汽车贴上get的标签（设置method为get），而且要求把传送的数据放在车顶上（url中）以方便记录。
如果是post请求，就要在车上贴上post的标签，并把货物放在车厢里（request body中）。
当然，你也可以在用get的时往车厢内偷偷藏点货物，但这并不不光彩；也可以在post的时候在车顶上也放一些数据，也会让人觉得傻乎乎的。
http只是个行为准则，而get和post本质上就是tcp链接，并无差别。但是由于http的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
追问2：那你刚才说的url中传送参数的长度限制在get和post中都是怎么样的呢？
其实在web中啊，还有另一个重要的角色：运输公司。
不同的浏览器client端（发起http请求）和服务器server端（接受http请求）就是不同的运输公司。
虽然理论上，你可以在车顶上无限的堆货物（url中无限加参数）。但是运输公司可不傻，装货和卸货也是有很大成本的，他们会限制单次运输量来控制风险，数据量太大对浏览器和服务器都是很大负担。
业界不成文的规定是：（大多数）浏览器通常都会限制url长度在2k个字节，而（大多数）服务器最多处理64k大小的url。
超过的部分，恕不处理。如果你用get服务，在request body偷偷藏了数据，不同服务器的处理方式也是不同的，有些服务器会帮你卸货，读出数据，有些服务器直接忽略。
所以，虽然get可以带request body，却不能保证一定能被接收到。
我之前处理过一个bug，用户反应查询没有响应，同事查了日志后才发现有几个参数都是undefined，很奇怪，最后发现原来是因为get请求第一个查询参数太长了，导致url后面的部分服务器无法接收 ，后来把请求改成post，将参数放在request body后就可以了。
追问3：那么你知道get、post请求发送的数据包有什么不同吗？
嗯嗯，是这样的，get请求时产生一个tcp数据包；post请求时产生两个tcp数据包。
- get：浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
- post：浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
就像是get只需要汽车跑一趟就把货送到了，而post得跑两趟，第一趟，先去和服务器打个招呼“老铁，我等下要送一批货来，你们准备接收一下哈”，然后再回头把货送过去。
因为post需要两步，理论上时间上消耗的要多一点，看起来get比post更有效。但并不是，后来发现原来是个坑。在我看来：
1.get与post都有自己的语义，不能随便混用。
2.据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的tcp在验证数据包完整性上，有非常大的优点。
3.并不是所有浏览器都会在post中发送两次包，firefox就只发送一次。我去年用chrome浏览器测试发现也是只发送一次，所以我认为get、post性能差可以人为忽略。
总结
本篇文章就到这里了，希望能给你带来帮助，也希望您能够多多关注的更多内容！