9.5 http tcp https总结
http协议
-
是什么：Hyper Text Transfer Protocol超文本传输协议 ------基于TCP/IP通信来传递数据
-
协议分层
-
应用层（应用层为程序提供服务，表示层进行数据格式转化加密、会话层建立管理维护会话）
-
传输层建立管理维护端到端的连接
-
网络层找地址和路由
-
数据链路层提供介质访问
- 物理层
-
-
HTTP属于应用层
-
工作：客户端终端（用户）和服务器端（网站）请求和应答的标准（TCP），客户端user agent发起一个HTTP请求到服务器server上指定端口
基于请求报文---响应报文
-
请求报文
-
请求行------请求方法，url，http版本
-
请求头：用来说明服务器要使用的附加信息
-
空行：必须
-
请求主体：请求的数据
http状态码
-
100 Continue 客户端应当继续发送请求。这个临时响应是用来通知客户端它的部分请求已经被服务器接收，且仍未被拒绝
-
1xx：指示信息–表示请求已接收，继续处理。
-
101 Switching Protocols
服务器已经理解了客户端的请求，并将通过Upgrade 消息头通知客户端采用不同的协议来完成这个请求。
-
102 代表处理将被继续执行。
-
-
2xx：成功–表示请求已被成功接收、理解、接受。
-
200 OK 请求已成功，请求所希望的响应头或数据体将随此响应返回。出现此状态码是表示正常状态。
-
201 Created 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随Location 头信息返回。假如需要的资源无法及时建立的话，应当返回 '202 Accepted'。
-
202 Accepted 服务器已接受请求，但尚未处理。正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。在异步操作的场合下，没有比发送这个状态码更方便的做法了
-
203 Non-Authoritative Information 服务器已成功处理了请求，但返回的实体头部元信息不是在原始服务器上有效的确定集合，而是来自本地或者第三方的拷贝
-
204 No Content 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。
-
205 Reset Content 服务器成功处理了请求，且没有返回任何内容。但是与204响应不同，返回此状态码的响应要求请求者重置文档视图。该响应主要是被用于接受用户输入后，立即重置表单，以便用户能够轻松地开始另一次输入。
-
-
3xx：重定向–要完成请求必须进行更进一步的操作。
-
301 Moved Permanently 被请求的资源已永久移动到新位置
-
302 Move Temporarily 请求的资源临时从不同的 URI响应请求。由于这样的重定向是临时的，客户端应当继续向原有地址发送以后的请求
-
303 See Other 对应当前请求的响应可以在另一个 URL 上被找到，而且客户端应当采用 GET 的方式访问那个资源。同时，303响应禁止被缓存。
-
304 Not Modified 如果客户端发送了一个带条件的 GET 请求且该请求已被允许，而文档的内容（自上次访问以来或者根据请求的条件）并没有改变，则服务器应当返回这个状态码。
-
305 Use Proxy 被请求的资源必须通过指定的代理才能被访问。
-
-
4xx：客户端错误–请求有语法错误或请求无法实现。
-
400 Bad Request 1、语义有误，当前请求无法被服务器理解。除非进行修改，否则客户端不应该重复提交这个请求。 2、请求参数有误。
-
401 Unauthorized 当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。
-
402 Payment Required 该状态码是为了将来可能的需求而预留的。
-
403 Forbidden 服务器已经理解请求，但是拒绝执行它。
-
404 Not Found 请求失败，请求所希望得到的资源未被在服务器上发现。
-
405 Method Not Allowed 请求行中指定的请求方法不能被用于请求相应的资源。
-
406 Not Acceptable 请求的资源的内容特性无法满足请求头中的条件，因而无法生成响应实体。
-
408 Request Timeout 请求超时。客户端没有在服务器预备等待的时间内完成一个请求的发送。客户端可以随时再次提交这一请求而无需进行任何更改。
-
409 Conflict 由于和被请求的资源的当前状态之间存在冲突，请求无法完成。
-
410 Gone 被请求的资源在服务器上已经不再可用，而且没有任何已知的转发地址。
-
-
5xx：服务器端错误–服务器未能实现合法的请求。
-
500 Internal Server Error 服务器遇到了一个未曾预料的状况，导致了它无法完成对请求的处理。一般来说，这个问题都会在服务器端的源代码出现错误时出现。
-
501 Not Implemented 服务器不支持当前请求所需要的某个功能。当服务器无法识别请求的方法，并且无法支持其对任何资源的请求。
-
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
-
503 Service Unavailable 由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。如果能够预计延迟时间，那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。
-
504 Gateway Timeout 作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器（URI标识出的服务器，例如HTTP、FTP、LDAP）或者辅助服务器（例如DNS）收到响应。
-
505 HTTP Version Not Supported 服务器不支持，或者拒绝支持在请求中使用的 HTTP 版本
URI：uniform resource identifier---唯一的标识
URL：uniform resource locator--统一资源定位器，它是一种具体的URI
-
-
-
-
响应报文
-
状态行：由HTTP协议版本号， 状态码， 状态消息
-
响应头：用来说明客户端要使用的一些附加信息
-
空行：必须
-
响应主体：服务器返回给客户端的文本信息
-
-
-
原理过程
-
客户端在应用层准备一个http请求--请求报文
-
在传输层进行数据分割，为了能准确无误地将数据送到目标，tcp采用三次握手，
-
建立连接之后，数据到达网络层，ip负责把数据传送给服务器，传送需要ip地址和mac地址，ip协议找到地址之后
-
到达链路层发给服务器
-
服务器收到数据通过分层还原http请求，返回响应报文
-
断开tcp连接
-
客户端进行渲染，
-
-
请求方法
-
get：读取数据
-
post：创建新的资源或修改现有资源
-
Put：向指定资源位置上传其最新内容。
-
DELETE：请求服务器删除Request-URI所标识的资源。
-
head：都是向服务器发出指定资源的请求。只不过服务器将不传回资源的本文部分
-
OPTIONS：可使服务器传回该资源所支持的所有HTTP请求方法。用'*'来代替资源名称
-
CONNECT：预留给能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接
-
TRACE：回显服务器收到的请求，主要用于测试或诊断。
get和post的区别
-
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）
-
\1. GET与POST都有自己的语义，不能随便混用。
\2. 如果网络环境好的话，发一次包的时间和发两次包的时间差别基本可以无视。如果网络环境差的话，两次包的TCP在验证数据包完整性上，有非常大的优点。
\3. 并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
-
GET在浏览器回退时是无害的，而POST会再次提交请求。
-
-------GET请求会被浏览器主动cache，而POST不会，除非手动设置。
-
------GET请求只能进行url编码，而POST支持多种编码方式。
-
------GET请求参数会被完整保留在浏览器历史记录里，而POST中的参数不会被保留。
-
------GET请求在URL中传送的参数是有长度限制的，而POST么有。-----对参数的数据类型，GET只接受ASCII字符，而POST没有限制。
-
------GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。
-
------GET参数通过URL传递，POST放在Request body中
-
-
-
http是无状态的协议，每次请求都是独立的所以服务器不能分辨每次请求的发送者是不是同一人，每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间，并且可以提高并发性能，不能和每个用户建立长久的连接，造成很多tcp建立断开，增加通信开销
-
持久性连接：http/1.0：只要一端没有明确提出断开链接就保持链接状态
-
从HTTP/1.1起，默认都开启了Keep-Alive，保持连接特性，简单地说，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接 Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间
TCP/IP
-
面向连接的运输层协议，提供可靠的服务，字节流，双全工通信
-
TCP 负责应用软件（比如你的浏览器）和网络软件之间的通信。
-
tcp通过socket套接字连接
-
停止等待协议：a--------------->b，a发送数据给b（1，2，3，4），发送1之后要收到b的确认之后才会继续发送2
-
无差错情况就是上面的
-
出现差错：就是b没有收到1或者收到了但是1错误了，b就不会发送确认，可靠传输协议设计：a只要超过一段时间没有收到确认就认为刚才发送的分组丢失就重传发送过的分组，实现超时重传就是在发送分组的时候设置一个超时计时器
-
确认丢失和迟到：就会重复收到确认和重复重传
-
-
滑动窗口ARQ协议：不是一个分组一个分组的发送，而是位于发送窗口的都可以发送不需要等待确认，容易实现，缺点是不能想发送方反应接收到的所有分组信息
-
ACK：确认序号有效。 TCP协议规定，只有ACK=1时有效，也规定连接建立后所有发送的报文的ACK必须为1
SYN：发起一个新连接。当SYN=1而ACK=0时，表明这是一个连接请求报文，
FIN：释放一个连接。当 FIN = 1 时，表明此报文段的发送方的数据已经发送完毕，并要求释放连接。
-
tcp传输数据是报文段：首部+数据
-
tcp建立连接三次握手：
建立连接时，客户端发送SYN包（SYN=1）到服务器，并进入到SYN-send状态，等待服务器确认------请求建立新连接
-
服务器收到SYN包，必须确认客户的SYN（ack=i+1）,同时自己也发送一个SYN包（SYN=k）,即SYN+ACK包，此时服务器进入SYN-recv状态--------“确认客户端的报文Seq序号有效，服务器能正常接收客户端发送的数据，并同意创建新连接
-
客户端收到服务器的SYN+ACK包，向服务器发送确认报ACK（ack=k+1）,此包发送完毕，客户端和服务器进入established状态，完成三次握手，客户端与服务器开始传送数据。-------明确了从客户端到服务器的数据传输是正常的，结束SYN-SENT阶段。并返回最后一段TCP报文
-
-
断开连接四次挥手
1. 第一次挥手：Client发送一个FIN，用来关闭Client到Server的数据传送，Client进入fin_wait_1，即半关闭阶段。表示客户端没有数据发送了--------客户端仍然能接 收从服务器端传输过来的数据。
-
第二次挥手：Server收到FIN后，发送一个ACK给Client，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），Server进入close_wait，（半关闭状态）。表示同意关闭请求
前两次挥手"既让服务器端知道了客户端想要释放连接，也让客户端知道了服务器端了解了自己想要释放连接的请求。于是，可以确认关闭客户端到服务器端方向上的连接了
-
第三次挥手：服务器端自从发出ACK确认报文之后，经过CLOSED-WAIT阶段，做好了释放服务器端到客户端方向上的连接准备，再次向客户端发出一段TCP报文FIN。---------停止在服务器端到客户端的方向上发送数据，但是服务器端仍然能够接收从客户端传输过来的数据。
-
第四次挥手：Client收到报文后，确认了服务器端已做好释放连接的准备，结束FIN-WAIT-2阶段，进入TIME-WAIT阶段，-------接收到服务器准备好释放连接的信号
后“两次挥手”既让客户端知道了服务器端准备好释放连接了，也让服务器端知道了客户端了解了自己准备好释放连接了。于是，可以确认关闭服务器端到客户端方向上的连接了，由此完成“四次挥手”。
随后客户端开始在TIME-WAIT阶段等待2MSL（msl：一段TCP报文在传输过程中的最大生命周期）
为的是确认服务器端是否收到客户端发出的ACK确认报文
客服端发送确认报文不能确定服务端是否能够收到，如果服务端没有在1mls没有收到确认报文就会向客户端再次发出fin报文，
如果客户端在2mls再次收到服务端的fin，就知道服务器没有收到自己的确认报文，就再次发出ack确认报文重新计时
然后客户端在2msl没有收到服务端的fin那么服务端就正常接受了确认报文，客户端就可以进去closed阶段完成四次挥手
-
-
三次握手不是二次的原因：如果A发送了两次请求给B，第一次由于其他原因没有及时到达b，而第二次是正常的得到了b的确认并且建立了连接，
之后第一个请求又到达了b，然后b又回应，如果只有两次握手这个连接就建立起来了，但是a收到回应自己又没有发送请求所以不会理会这个回应，b以为已经建立了连接就一直等待a发送数据但是a不会发送就浪费了b的资源
如果是三次握手，b发送回应a不确认的话这个连接就没有建立起来
所以第三次握手，a发送一次确认是为了防止：如果客户端迟迟没有收到服务器返回的确认报文，这时他会放弃连接，重新启动一条连接请求， 但问题是：服务器不知客户端没收到，所以他会收到两个连接请求，白白浪费了一条连接开销。而四次或更多次的握手，则是浪费资源，因为三次握手已经可以达到的效果没有必要再去多次连接， 或者形成死锁：建立了连接但是a没有给b要发送的数据的一些信息，b不管收到啥都不会理会，就一直等待，而a发送了数据一直得不到回应就一直发送数据
-
这个问题的本质是, 信道不可靠, 但是通信双发需要就某个问题达成一致. 而要解决这个问题, 无论你在消息中包含什么信息, 三次通信是理论上的最小值. 所以三次握手不是TCP本身的要求, 而是为了满足"在不可靠信道上可靠地传输信息"这一需求所导致的. 请注意这里的本质需求,信道不可靠, 数据传输要可靠. 三次达到了, 那后面你想接着握手也好, 发数据也好, 跟进行可靠信息传输的需求就没关系了. 因此,如果信道是可靠的, 即无论什么时候发出消息, 对方一定能收到, 或者你不关心是否要保证对方收到你的消息, 那就能像UDP那样直接发送消息就可以了.”。
-
三次握手但是四次挥手的原因
建立连接时，被动方服务器端进入“握手”阶段并不需要任何准备，可以直接返回SYN和ACK报文，开始建立连接。
释放连接时，被动方服务器，突然收到主动方客户端释放连接的请求时并不能立即释放连接，因为还有必要的数据需要处理，所以服务器先返回ACK确认收到报文，经过CLOSE-WAIT阶段准备好释放连接之后，才能返回FIN释放连接报文。
