这是我参与更文挑战的第2天，活动详情查看： 更文挑战
hello，这里是混迹江湖多年双眼依然炯炯有神的大白。
今天坑来了有点忧郁有点迷茫的新晋程序员王强（化名）给大家分享java面试宝典。
通篇充满忧郁气质，请大家温柔对待这位忧郁小蓝孩（写的不好，轻喷）
以下内容可代入王强同志的忧郁气息去阅读，如果想象不出来，我给你们一张图感受一下。
我是王强，我很忧郁 （说完猛吸一口烟，缓缓吐出），今天被大白强拉来营业，那就勉强讲一下java面试官可能会问也可能完全不会问的网络通信类面试题。
面试开始～～～
1、http协议的状态码有哪些？含义是什么？
大概有200、301、302、400、401、403、404、500、503这么些吧。
200 当然就是OK， 客户端请求成功，好开心，又侥幸请求成功了呢，希望下一次也这么幸运。
ps：有时候虽然接口请求是200，返回结果却还是“网络异常”，这可能是dubbo接口挂了，对方没有提供服务（查下日志就能看出来）。
org.apache.dubbo.rpc.RpcException: No provider available from ......
又或者dubbo服务也是正常，测试同学还是喊着怎么挂了打不开啦，一看发现是这傻缺连了代理又没打开代理工具，幸亏我够忧郁没有被看出其实内心很慌张。
这里推荐常用的抓包工具Charles，再也不用卑微找测试弟弟要接口参数和返回结果咯。
301 Moved Permanently（永久移除)，请求的URL已移走。Response中应该包含一个 Location URL，说明资源现在所处的位置；
302 found 重定向；
400 Bad Request 客户端请求有语法错误，不能被服务器所理解；
401 Unauthorized 请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用；
403 Forbidden 服务器收到请求，但是拒绝提供服务；
404 Not Found 请求资源不存在，eg：输入了错误的URL。（哦 原来是测试同学输错了地址报404，又是那个傻缺。）
500 Internal Server Error 服务器发生不可预期的错误，可怕的噩梦，这次服务真的是挂了。
503 Server Unavailable 服务器当前不能处理客户端的请求，一段时间后可能恢复正常。
2.什么是cookie？session和cookie有什么区别？
首先明白用户通过网络连接上服务器，这时需要有唯一通行证让服务器能一一识别用户，而这个唯一通行证就是cookie，他可以作为http协议跟踪用户会话的一种机制。
Cookie意为“甜饼”，是由W3C组织提出，最早由Netscape社区发展的一种机制。目前Cookie已经成为标准，所有的主流浏览器如IE、Netscape、Firefox、Opera等都支持Cookie。扒拉扒拉，这就是一些常规的理论背景，知道一下就行。
session就是“会话”的意思，开发者为了实现用户和服务器之间的中断和继续等操作，将这样的一对一交互抽象出来成为“会话”，进而衍生出session（会话状态），所以说session是一种抽象态。而cookie是一种实质存在在header中的信息。
cookie存储在客户端，session保存在服务端。
cookie不安全，存在浏览器中容易被窃取并用于其他操作。
session存在服务端，较安全，但是比较占内存影响服务器性能。
这种问题一般属于开放题，都是通过每个人自己的理解讲出来的，没有什么特别标准的答案，回答到几个点子就行。
3、说下你理解的TCP的三次握手和四次挥手？
三次握手（TCP建立连接过程）
1.第一次握手：建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x;然后，客户端进入SYN_SEND状态，等待服务器的确认;
2.第二次握手：服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1);同时，还要发送SYN请求信息，将SYN置为1，Sequence Number为y;服务器端将上述所有信息放到一个报文段(即SYN+ACK报文段)中，一并发送给客户端，告诉服务端我已经收到你的消息，此时服务器进入SYN_RECV状态;
3.第三次握手：客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，告诉他我这里已经确认你收到啦，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。
追问：为什么是三次不是两次呢？
这是为了防止失效的请求误发给服务端。第一次握手后，服务端要发出确认接受信息的反馈给客户端，然而一直得不到客服端的回信（因为客户端这时候已经closed掉啦），一直等等等等等，就会造成资源浪费。（讲到这，牵动起了我忧郁的神经，让我45度仰望天空回想起那年夏天我和你躲在那一大片宁静的海...）
列举一下发生场景就比如请求量很多高并发了，客户端在发出一条请求后，一直被阻塞中得不到回应，于是客户端再次发送一条请求，而这第一条就是失效的请求，他终将会缓慢的从阻塞中释放出来继续发送到服务端，服务端又会反馈给客户端，但此时的客服端已经关闭，不再回复任何信息，服务端就一直等待中，资源就这么浪费掉。
四次挥手（TCP断开连接过程）
1.第一次分手：主机1(可以使客户端，也可以是服务器端)，设置FIN=1，seq=u，向主机2发送一个FIN报文段;此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了;
2.第二次分手：主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，ACK=1，seq=v，ack=u+1;主机1进入FIN_WAIT_2状态；主机2告诉主机1，我也没有数据要发送了，可以进行关闭连接了;
3.第三次分手：主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入CLOSE_WAIT状态；
4.第四次分手：主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接（closed）；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了（closed）。
看得出来主机双方都是在第四次分手的时候closed掉滴。（干了这杯酒，再爱也不回头）
（大白：很通俗的理解，很隐晦的表达。 王强：（很忧郁的撇了我一眼））
The End
来自忧郁王子 王强
再次鸣谢王强同志的倾情解说。（他似乎有点意犹未尽，下次可以继续抓来讲）
身边接触了很多程序员，我要为他们平反，他们绝不是格子衫和秃头的代表，是时而忧郁时而顽皮，时而聪慧过人时而双目呆滞，静如处子 ，动如疯兔，文能造火箭，武能打产品，呸，打老虎的一群可爱人儿。
请期待下一位有个性的程序员X的分享吧。拜了个白
喜欢就点点关注，下期见。 （要赞要关注都要的这么理直气壮）
（封面是王强强烈要求放的，名曰忧郁王子花泽类）
