网络编程小知识

为什么连接的时候是三次握手，关闭的时候却是四次握手？

答：因为当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处报错
进程之间的数据是不安全的