为什么连接的时候是三次握手，关闭的时候却是四次握手？
答：因为当Server端收到Client端的SYN连接请求报文后，可以直接发送SYN+ACK报文。
其中ACK报文是用来应答的，SYN报文是用来同步的。但是关闭连接时，当Server端收到FIN报文时，很可能并不会立即关闭SOCKET，
所以只能先回复一个ACK报文，告诉Client端，"你发的FIN报文我收到了"。只有等到我Server端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送。故需要四步握手。
为什么不能用两次握手进行连接？
答：3次握手完成两个重要的功能，既要双方做好发送数据的准备工作(双方都知道彼此已准备好)，也要允许双方就初始序列号进行协商，这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手，死锁是可能发生的。
作为例子，考虑计算机S和C之间的通信，假定C给S发送一个连接请求分组，S收到了这个分组，并发 送了确认应答分组。
按照两次握手的协定，S认为连接已经成功地建立了，可以开始发送数据分组。可是，C在S的应答分组在传输中被丢失的情况下，将不知道S 是否已准备好，不知道S建立什么样的序列号，
C甚至怀疑S是否收到自己的连接请求分组。在这种情况下，C认为连接还未建立成功，将忽略S发来的任何数据分 组，只等待连接确认应答分组。而S在发出的分组超时后，重复发送同样的分组。
这样就形成了死锁。
如果已经建立了连接，但是客户端突然出现故障了怎么办？
TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。
服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，
以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。
为何基于tcp协议的通信比基于udp协议的通信更可靠？
TCP的可靠保证，是它的三次握手双向机制，这一机制保证校验了数据，保证了他的可靠性。
而UDP就没有了，UDP信息发出后,不验证是否到达对方,所以不可靠。
不过UDP的速度是TCP比不了的，而且UDP的反应速度更快，
什么是socket？简述基于tcp协议的套接字通信流程。
Socket是应用层与TCP/IP协议族通信的中间软件抽象层，它是一组接口。 在设计模式中，Socket其实就是一个门面模式，他把复杂的TCP/IP协议族隐藏在Socket接口后面。 对用户来说，一组简单的接口就是全部，以符合制定的协议。
什么是黏包？ socket 中造成黏包的原因是什么？ 哪些情况会发生黏包现象？
同时执行多条命令之后，得到的结果很可能只有一部分，在执行其他命令的时候又接收到之前执行的另外一部分结果，这种现象就叫黏包。
只有TCP有黏包现象，UDP永远不会发生黏包。
当发送端缓冲区的长度大于网卡的MTU（网络上传送的最大数据包，单位是字节。）时，TCP会将这次发送的数据拆成几个数据包发送出去。增加丢包率和降低网络速度。
会发生黏包的两种情况：
1）发送方的缓存机制：发送端需要等缓冲区满才发送出去，造成黏包。（发送数据时间间隔很短，数据很小，就会合到一块，产生黏包）
2）接收方的缓存机制：接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端直接收到一小段数据，服务端下次在接收的时候还是从缓冲区拿上次遗留的数据，产生黏包）
黏包现象只发生在tcp协议中：
1）从表面上看，黏包问题主要是因为发送方和接收方的缓存机制、tcp协议面向流通信的特点。
2）实际上，主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的
列举Http请求中的状态码？
100——客户必须继续发出请求 101——客户要求服务器根据请求转换HTTP协议版本 200——交易成功 201——提示知道新文件的URL 202——接受和处理、但处理未完成 203——返回信息不确定或不完整 204——请求收到，但返回信息为空 205——服务器完成了请求，用户代理必须复位当前已经浏览过的文件 206——服务器已经完成了部分用户的GET请求 300——请求的资源可在多处得到 301——删除请求数据 302——在其他地址发现了请求数据 303——建议客户访问其他URL或访问方式 304——客户端已经执行了GET，但文件未变化 305——请求的资源必须从服务器指定的地址得到 306——前一版本HTTP中使用的代码，现行版本中不再使用 307——申明请求的资源临时性删除 400——错误请求，如语法错误 401——请求授权失败 402——保留有效ChargeTo头响应 403——请求不允许 404——没有发现文件、查询或URl 405——用户在Request-Line字段定义的方法不允许 406——根据用户发送的Accept拖，请求资源不可访问 407——类似401，用户必须首先在代理服务器上得到授权 408——客户端没有在用户指定的饿时间内完成请求 409——对当前资源状态，请求不能完成 410——服务器上不再有此资源且无进一步的参考地址 411——服务器拒绝用户定义的Content-Length属性请求 412——一个或多个请求头字段在当前请求中错误 413——请求的资源大于服务器允许的大小 414——请求的资源URL长于服务器允许的长度 415——请求资源不支持请求项目格式 416——请求中包含Range请求头字段，在当前请求资源范围内没有range指示值，请求也不包含If-Range请求头字段 417——服务器不满足请求Expect头字段指定的期望值，如果是代理服务器，可能是下一级服务器不能满足请求 500——服务器产生内部错误 501——服务器不支持请求的函数 502——服务器暂时不可用，有时是为了防止发生系统过载 503——服务器过载或暂停维修 504——关口过载，服务器使用另一个关口或服务来响应用户，等待时间设定值较长 505——服务器不支持或拒绝支请求头中指定的HTTP版本
列举Http请求中常见的请求头和响应头？
请求头： accept:浏览器通过这个头告诉服务器，它所支持的数据类型 Accept-Charset: 浏览器通过这个头告诉服务器，它支持哪种字符集 Accept-Encoding：浏览器通过这个头告诉服务器，支持的压缩格式 Accept-Language：浏览器通过这个头告诉服务器，它的语言环境 Host：浏览器通过这个头告诉服务器，想访问哪台主机 If-Modified-Since: 浏览器通过这个头告诉服务器，缓存数据的时间 Referer：浏览器通过这个头告诉服务器，客户机是哪个页面来的 防盗链 Connection：浏览器通过这个头告诉服务器，请求完后是断开链接还是何持链接 响应头 Location: 服务器通过这个头，来告诉浏览器跳到哪里 Server：服务器通过这个头，告诉浏览器服务器的型号 Content-Encoding：服务器通过这个头，告诉浏览器，数据的压缩格式 Content-Length: 服务器通过这个头，告诉浏览器回送数据的长度 Content-Language: 服务器通过这个头，告诉浏览器语言环境 Content-Type：服务器通过这个头，告诉浏览器回送数据的类型 Refresh：服务器通过这个头，告诉浏览器定时刷新 Content-Disposition: 服务器通过这个头，告诉浏览器以下载方式打数据 Transfer-Encoding：服务器通过这个头，告诉浏览器数据是以分块方式回送的 Expires: -1 控制浏览器不要缓存 Cache-Control: no-cache Pragma: no-cache
队列，管道
队列：管道+锁
处理任意数据类型
进程之间的数据安全
管道：有两端
需要关闭掉不用的所有端口，才会在recv处报错
进程之间的数据是不安全的