Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

计算机网络几个基础的点(线下分享の附属品) #32

Open
tangxueer opened this issue May 21, 2016 · 1 comment
Open

Comments

@tangxueer
Copy link

tangxueer commented May 21, 2016

主要是根据上次琦哥说到的计算机网络中几点展开,是我正好趁着这次干事分享学习后的个人体会,因为是在网上快速学习的,没看过系统的书,理解错的地方请大佬们直接指出哦~(弱弱地飘过~)

一.报文结构

1.请求报文:


举个栗子:从前有个人开了家征婚事务所,有一位叫杰艾斯的男子看中了她脑内写码的技能,想要一张征婚报名表,并要求在10:00之前送到A4二楼。
在这个场景里,征婚报名表就是请求的报文体,而10:00,A4,名叫艾杰斯这类附加信息就是报文头。

常见请求报文头属性:
Accept:请求内容的类型
Referrer:完整的url
Cache-control:缓存的时间选择
Cookie:包含sessionid,是服务器区别多个客户端的重要凭证。

2.响应报文:

响应状态码:
1xx 请求已收到,正在处理中
2xx 处理成功
3xx 重定向到其它地方
4xx 错误在客户端,如客户端的请求一个不存在的资源,客户端未被授权,禁止访问等。
5xx 错误在服务端,如服务端抛出异常,路由出错,HTTP版本不支持等

常见的响应状态码有:
200: 处理成功
303 see others: 重定向到其他页面
304 not modified: 该资源以前请求过了,提示用户直接使用本地的缓存
(补充:last-Modified If-Modified-Since,当第一次请求资源时,会生成一个last-modified时间标识,客户端通过查询该标识来确认是否以前请求过该资源)
404 not found: 该页面不存在等
500 internal server error: 服务端抛出异常等

响应报文头属性:
ETag:实体标签,是一种随状态而随时改变的资源状态标识。形式多样,廉洁的时间戳,复杂的哈希算法等。
Location:重定向页面的url,指示了303响应状态码所跳转的页面。
Set-cookie: 指示用户更新sessionid
e.g: customer=huangxp;path=/foo;domain=.ibm.com;
expires= Wednesday, 19-OCT-05 23:12:40 GMT; [secure]
customer为一个“名称 = 值”对。
path = /foo 表示控制访问路径,只有访问/foo下的网页cookie才被发送。
domain = .ibm.com 非空时指定发送到具体服务器,为空时为默认的链接服务器。
Expires = …指定cookie失效的时间
Secure 开启SSL加密模式

二.TCP的连接与断开过程

先了解一些在TCP协议中的常见状态:
SYN表示建立连接,
FIN表示关闭连接,
ACK表示响应,
PSH表示有 DATA数据传输,
RST表示连接重置。

1.TCP的连接——三次握手:

第一次握手:客户端发送位码为syn=1,随机产生seq number=1234567的数据包到服务器,服务器由SYN=1知道,客户端要求建立联机;
第二次握手:服务器收到请求后要确认联机信息,向客户端发送ack number=seq+1,syn=1,ack=1,随机产生seq number=7654321的包,即发送ACK+SYN包;
第三次握手:客户端收到后检查ack number是否正确,即第一次发送的seq number+1,以及位码ack是否为1,若正确,客户端会再发送ack number=seq+1,ack=1,服务器收到后确认seq值与ack=1则连接建立成功。客户端和服务器进入ESTABLISHED状态,完成三次握手。

目的:
防止已经失效的连接请求又传到了服务端。如果客户端与服务器是直接传输直接接受的关系,那么服务器端会接受已经失效的连接请求,认为双方已经建立了联系,所以一直
等待数据从客户端发来,这样会拖慢服务器进程,浪费资源。

2. TCP的断开——四次挥手:

第一次挥手:主动关闭方调用close,发送一个FIN给被动方
第二次挥手:被动关闭方接收到FIN,并发送确认包ACK给主动方
第三次挥手:一段时间后,被动方也调用close,发送一个FIN给原主动方
第四次挥手:主动方接收确认这个FIN,并发出确认包(TIME_WAIT)

总过程图:

状态时序图:

3. TIME_WAIT状态:

概念:
又称2MSL状态,而MSL是任何报文段被丢弃前在网络内的最长时间。当TCP连接完成四个报文段的交换时,即使两端的应用程序结束,主动关闭的一方还将继续等待一定时间(2-4分钟)才关闭连接。

原因:
其一,保证发送的ACK会成功发送到对方。如果ACK丢失,则服务器将重新发送它的最终FIN值,因此客户必须维护状态信息,以允许它重新发送最终那个ACK。要是客户不维护状态信息,它将响应以一个RST,该分节将被服务器解释成一个错误。这也说明了为什么执行主动关闭的那一端是处于TIME_WAIT状态的那一端,因为可能不得不重传最终那个ACK的就是那一端。
其二,防止新的连接被老的连接干扰。 当老的连接断开之后,在相同的服务器与客户端建立新的连接,由于它们的IP地址与端口都相同,曾经的连接很有可能干扰新建立的连接,所以需要有TIME_WAIT状态,使老的连接在2MSL的持续时间内失效而被丢弃。

三.HTTPS的基本原理

HTTPS较HTTP的特点:
HTTP+SSL证书加密,安全性高。

基本流程:

  1. 客户端向服务器发送HTTP请求。
  2. 服务器生成公钥和私钥。(公钥就是锁,私钥就是钥匙)
  3. 服务器把公钥传给客户端,该公钥就是证书。
  4. 客户端的SSL过程:客户端先判断证书是否合法,若不合法则发出警告,若合法则先产生一个随机数,用加密算法加密该数,并生成公钥和私钥。
  5. 客户端把随机数的公钥发送给服务器。
  6. 服务器根据先前存的私钥解密客户端发的公钥,得到了随机数,再把传递的内容信息与该随机数用对称加密算法结合为一个秘钥。
  7. 服务器把该秘钥发送给客户端。
  8. 客户端根据先前存的私钥解密发来的秘钥,得到服务器发送的内容。

参考资料:
http报文详解
tcp的连接与断开
https工作原理
https工作原理与tcp握手机制

by 汤雪儿

@hongruiqi
Copy link

HTTPS的流程有点问题
可以看见这个
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants