流量控制
目的:
如果发送方发送数据过快,接收方来不及接收,就会导致数据丢失
实现:
接收方每次收到数据包,可以在发送确定报文的时候,同时告诉发送方自己的缓存区还剩余多少是空闲的,我们也把缓存区的剩余大小称之为接收窗口大小,用变量win来表示接收窗口的大小。发送方收到之后,便会调整自己的发送速率,也就是调整自己发送窗口的大小,当发送方收到接收窗口的大小为0时,发送方就会停止发送数据,防止出现大量丢包情况的发生。
详细解释参考:https://www.cnblogs.com/kubidemanong/p/9987810.html
拥塞控制
目的:
防止过多的数据注入到网络中或者说在网络发生拥塞时降低数据的流入
实现:
详细解释参考:https://blog.csdn.net/LAf_HUAZAI/article/details/107066047
TIIME_WAIT 是TCP 连接关闭过程中的一个状态,第四次挥手后在主动关闭连接端出现,该状态会持续 2MSL 的时间,然后才会变为 CLOSED 状态,设置该状态的原因主要有两个:
关于这个问题似乎没有一个非常准确的定论,我也只会进行一个大致的分析。MSL(Maximum Segment Lifetime)意为报文最大生存时间,是任何报文在网络上存在的最长时间,超过这个时间报文将被丢弃,
RFC 中规定 MSL 为120秒,实际中经常被设置为30秒、1分钟、2分钟。
我们首先分析第 3 题中的目的 2,若是防止ACK丢失,则TIME_WAIT 应该设置为略大于接收端的 RTO,但RTO 是个变量,多次超时还会发生变化,发生多次ACK丢失时,TIME_WAIT 需要大于最后一次RTO的值,但此时接收端也已经接近因超时而断开连接了,TIME_WAIT 似乎意义不大了。
再来分析目的 1,防止数据污染。我也认为这是主要原因。从TIME_WAIT 前的最后一个ACK开始计算,该ACK在网络中的最大存活时间为 1MSL,若该ACK在到达接收端之前恰好时间超过MSL而被抛弃,接收端重发FIN,ACK,重发的报文最大存活时间也是MSL。注意 MSL 一般远大于 RTO,也就是说在 2MSL 之内 有两种情况,一是 ACK 成功到达对面,连接在 2MSL 后彻底断开;二是 ACK 丢失,接收端重发 FIN,ACK,计时器重新开始计时。总结就是在 2MSL 后,发送方和接收方之间的数据必然会发送完毕,不会造成数据污染。
每个 TCP 数据包都有一个序列号,接收方接收到后按照序列号重组
参考:https://blog.csdn.net/LAf_HUAZAI/article/details/107066047
方法 | 说明 |
---|---|
GET | GET请求会显示请求指定的资源。一般来说GET方法应该只用于数据的读取,而不应当用于会产生副作用的非幂等的操作中。它期望的应该是而且应该是安全的和幂等的。这里的安全指的是,请求不会影响到资源的状态。 |
HEAD | HEAD方法与GET方法一样,都是向服务器发出指定资源的请求。但是,服务器在响应HEAD请求时不会回传资源的内容部分,即:响应主体。这样,我们可以不传输全部内容的情况下,就可以获取服务器的响应头信息。HEAD方法常被用于客户端查看服务器的性能。 |
POST | POST请求会 向指定资源提交数据,请求服务器进行处理,如:表单数据提交、文件上传等,请求数据会被包含在请求体中。POST方法是非幂等的方法,因为这个请求可能会创建新的资源或/和修改现有资源。 |
PUT | PUT请求会身向指定资源位置上传其最新内容,PUT方法是幂等的方法。通过该方法客户端可以将指定资源的最新数据传送给服务器取代指定的资源的内容。 |
DELETE | DELETE请求用于请求服务器删除所请求URI(统一资源标识符,Uniform Resource Identifier)所标识的资源。DELETE请求后指定资源会被删除,DELETE方法也是幂等的。 |
CONNECT | CONNECT方法是HTTP/1.1协议预留的,能够将连接改为管道方式的代理服务器。通常用于SSL加密服务器的链接与非加密的HTTP代理服务器的通信。 |
OPTIONS | OPTIONS请求与HEAD类似,一般也是用于客户端查看服务器的性能。 这个方法会请求服务器返回该资源所支持的所有HTTP请求方法,该方法会用’*'来代替资源名称,向服务器发送OPTIONS请求,可以测试服务器功能是否正常。JavaScript的XMLHttpRequest对象进行CORS跨域资源共享时,就是使用OPTIONS方法发送嗅探请求,以判断是否有对指定资源的访问权限。 |
TRACE | TRACE请求服务器回显其收到的请求信息,该方法主要用于HTTP请求的测试或诊断。 |
PATCH | PATCH方法出现的较晚,它在2010年的RFC 5789标准中被定义。PATCH请求与PUT请求类似,同样用于资源的更新。二者有以下两点不同:1.PATCH一般用于资源的部分更新,而PUT一般用于资源的整体更新。2.当资源不存在时,PATCH会创建一个新的资源,而PUT只会对已在资源进行更新。 |
状态码 | 说明 |
---|---|
200 | 表示客户端发送的请求在服务端被正确处理 |
204 | 表示请求成功,但是响应报文不含实体的主体部分 |
205 | 表示请求成功,但是响应报文不含实体的主体部分,但是不同的是要求请求方重置内容 |
206 | 表示客户端发送的范围请求 |
301 | 永久重定向,表示请求的资源已分配了新的URL |
302 | 临时重定向,表示请求的资源临时分配了新的URL |
303 | 表示请求的资源还存在另外一个URL,可以通过GET请求访问 |
304 | 资源缓存,表示客户端发送的请求被允许,但是请求的内容没有改变 |
307 | 临时重定向,期望客户端保持请求方法不变向新的地址发出请求 |
400 | 表示请求的报文存在语法错误 |
401 | 表示发送的请求需要有通过HTTP认证的认证信息 |
403 | 表示请求被服务器拒绝 |
404 | 表示请求的资源不存在 |
500 | 服务器执行请求时发生错误 |
501 | 服务器不支持挡球请求所需要的某个功能 |
503 | 表示服务器宕机(超负载或者正在维护) |
其实状态码主要分为以下 5 类:
1** 信息,服务器收到请求,需要请求者继续执行操作
2** 成功,操作被成功接收并处理
3** 重定向,需要进一步的操作以完成请求
4** 客户端错误,请求包含语法错误或无法完成请求
5** 服务器错误,服务器在处理请求的过程中发生了错误
参考:https://juejin.im/post/5ab341e06fb9a028c6759ce0
参考:https://blog.csdn.net/YLBF_DEV/article/details/50266447
If-Modified-Since是标准的HTTP请求头标签,它的值等于服务端响应头中的 Last-Modified, 在发送HTTP请求时,把浏览器端缓存页面的最后修改时间一起发到服务器去,服务器会把这个时间与服务器上实际文件的最后修改时间进行比较。如果时间一致,那么返回HTTP状态码304(不返回文件内容),客户端接到之后,就直接把本地缓存文件显示到浏览器中。如果时间不一致,就返回HTTP状态码200和新的文件内容,客户端接到之后,会丢弃旧文件,把新文件缓存起来,并显示到浏览器中。
Cookie是客户端保存用户信息的一种机制,用来记录用户的一些信息,实际上Cookie是服务器在本地机器上存储的一小段文本,并随着每次请求发送到服务器。Cookie技术通过请求和响应报文中写入Cookie信息来控制客户端的状态。Cookie会根据响应报文里的一个叫做Set-Cookie的首部字段信息,通知客户端保存Cookie。当下客户端再向服务端发起请求时,客户端会自动在请求报文中加入Cookie值之后发送出去.之后服务端发现客户端发送过来的Cookie后,会检查是那个客户端发送过来的请求,然后对服务器上的记录,最后得到了之前的状态信息。
Session是服务端保存用来跟踪用户的状态的一种机制,服务端执行session机制时候会生成session的id值,这个id值会发送给客户端,客户端每次请求都会把这个id值放到http请求的头部发送给服务端,而这个id值在客户端会保存下来,保存的容器就是cookie,因此当我们完全禁掉浏览器的cookie的时候,服务端的session也会不能正常使用。注意Session不一定必须依赖Cookie,SessionID还可以保存在其它地方。
Cookie 与 Session 的区别:
1. cookie数据存放在客户的浏览器(客户端)上,session数据放在服务器上,但是服务端的session的实现对客户端的cookie有依赖关系的;
2. cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session;
3. session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能。考虑到减轻服务器性能方面,应当使用COOKIE;
4. 单个cookie在客户端的限制是3K,就是说一个站点在客户端存放的COOKIE不能超过3K。
参考:https://juejin.im/post/5aa783b76fb9a028d663d70a
图片来源:《图解HTTP》
Https原理及过程