java中的网络支持
InetAddress:用于表示网络上的硬件资源,即 IP 地址;
URL:统一资源定位符;
Sockets:使用 TCP 协议实现网络通信;
Datagram:使用 UDP 协议实现网络通信。
Tcp和Udp区别
Tcp代表传输控制协议。是面向连接的协议,提供稳定的双向通信功能。Tcp连接的建立需要经过“三次握手”才能完成,为了提供稳定的数据传输功能,其本身提供了超时重传机制,因此,具有很高的稳定性。TCP是面向连接的,可靠的,缓慢的,可靠交付以及保证消息顺序的。TCP头开销也比UDP高得多,因为它每个数据包中要发送更多的元数据。TCP头的大小是20个字节。如果你不想丢失任何消息,使用TCP协议,而
Udp代表用户数据报协议。是无连接的,提供不稳定的单向通信功能。Udp也能提供双向通信功能。在性能上,Udp具有更好的效率。其缺点是不能保证数据一定能正确传输,尤其是网络拥塞的情况下。UDP是无连接的,不可靠的,没有序列保证,但是一个快速传输的协议。UDP头大小是8个字节。UDP能够高速传输数据,并且丢失少量的数据包是可以接受的,如视频流或在线多玩家游戏。
TCP
基本特性
面向连接
可靠性
往返时延和重传超时
数据排序
流量控制
全双工(能同时像对方发送消息)
TCP 的三次握手
假设 A 为客户端,B 为服务器端。
- 首先B处于LISTEN(监听)状态,等待客户的连接请求
- A向B发送请求报文段,SYN=1,ACK=0,选择一个初始的序列号x(第一次握手:客户端请求建立连接)
- B收到连接的请求报文段,如果同意建立连接,则向A发送连接确认报文段,SYN=1,ACK=1,确认号为x+1,同时选择一个初始的序列号y(第二次握手:服务端应答客户端,并请求建立连接)
- A收到B的连接确认报文段后,还要向B发出确认,确认号为y+1,序列号为x+1(第三次握手:客户端针对服务端请求确认应答)
- B收到A的确认后,连接建立
三次握手的原因
TCP是面向连接的,所以需要双方都确认连接的建立。
第三次握手是为了防止失效的连接请求到达服务器,让服务器错误的打开
失效的连接是指,客户端发送的请求连接在网络中滞留,客户端因为没有及时收到服务器端发送的连接确认,因此重新发送了连接请求。滞留的连接请求并没有丢失,之后还会到达服务器。如果不进行第三次握手,那么,服务器会误认为客户端重新请求连接,然后打开了连接。但并不是客户端真正的打开这个连接,因此客户端不会给服务器发送数据,这个连接就白白浪费了
TCP 的四次挥手
A 为客户端,B 为服务器端。
-
A发送连接释放报文段,FIN=1
-
B收到之后发出确认,此时TCP属于半关闭状态,B能向A发送数据但是A不能向B发送数据
-
当B不再需要连接时,发送连接释放请求报文段,FIN=1
-
A收到后发出确认,进入TIME-WAIT状态,等待2MSL时间后释放连接
-
B收到A 的确认后释放连接
-
第一次挥手:客户端发送关闭请求
-
第二次挥手:服务端响应客户端关闭请求
-
第三次挥手:服务端发送关闭请求
-
第四次挥手:客户端发送关闭确认请求
四次挥手的原因
TCP是全双工(即客户端和服务端可以相互发送和接受请求),所以需要双方都确认关闭连接
客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。
TIME_WAIT
客户端接收到服务器端的 FIN 报文后进入此状态,此时并不是直接进入 CLOSED 状态,还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由:
确保最后一个确认报文段能够到达。如果 B 没收到 A 发送来的确认报文段,那么就会重新发送连接释放请求报文段,A 等待一段时间就是为了处理这种情况的发生。
等待一段时间是为了让本连接持续时间内所产生的所有报文段都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文段。
Http
基础概念
协议:指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则
Http协议:超文本传输协议是一种通信协议,它允许将超文本标记语言(HTML)文档从web服务器传送到客户端的浏览器
URI(Uniform Resource Indentifier,统一资源标识符),用来标识一个资源
URI三个组成部分:1)访问资源的命名机制 2)存放资源的主机名 3)资源自身的名称,由路径表示,着重强调于资源 file://a:b/c.txt
URL(Uniform Resource Locator,统一资源定位符)
URL 的三个组成部分 1) 协议 2)存有该资源的主机Ip地址 3) 主机资源的具体地址
HTTP协议的特点
简单快速
无连接
无状态
http request和response
请求报文
响应报文
HTTP/1.0 与 HTTP/1.1
http1.0产生的背景
超文本传输协议(HyperText Transfer Protocol)伴随这计算机网络和浏览器的诞生,Http1.0也随之而来,处于计算机网络中的应用层
http1.0所做的优化
带宽:现阶段已解决
延迟:浏览器阻塞:浏览器对于同一域名,同时只能有四个连接
延迟:DNS查询:浏览器需要知道目标服务器的IP才能建立连接
延迟:建立连接:三次握手
http2.1和http1.0存在的问题
- HTTP1.X在传输数据时,每次都要重新建立连接,无疑增加了大量的延迟时间
- HTTP1.X在传输数据时,所有的传输内容都是明文,客户端和服务端都无法验证对方的身份
- HTTP1.X在使用的时,header里携带的内容过大,在一定程度上增加了传输的成本
http1.1和http1.0的区别
- 缓存处理
- 带宽优化以及网络连接的使用
- Host头处理
- 长连接
http长连接 短连接
当浏览器访问一个包含多张图片的 HTML 页面时,除了请求访问 HTML 页面资源,还会请求图片资源,如果每进行一次 HTTP 通信就要断开一次 TCP 连接,连接建立和断开的开销会很大。长连接只需要建立一次 TCP 连接就能进行多次 HTTP 通信。
所谓长连接指建立SOCKET连接后不管是否使用都保持连接,但安全性较差,
所谓短连接指建立SOCKET连接后发送后接收完数据后马上断开连接,一般银行都使用短连接
http get和post 的区别以及安全性
GET 和 POST 的请求都能使用额外的参数,但是 GET 的参数是以查询字符串出现在 URL 中,而 POST 的参数存储在实体主体中。
http状态码
- 100 Continue :表明到目前为止都很正常,客户端可以继续发送请求或者忽略这个响应。
- 200 OK
- 204 No Content :请求已经成功处理,但是返回的响应报文不包含实体的主体部分。一般在只需要从客户端往服务器发送信息,而不需要返回数据时使用。
- 206 Partial Content :表示客户端进行了范围请求。响应报文包含由 Content-Range 指定范围的实体内容。
- 301 Moved Permanently :永久性重定向
- 302 Found :临时性重定向
- 303 See Other :和 302 有着相同的功能,但是 303 明确要求客户端应该采用 GET 方法获取资源。
- 注:虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法,但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。
- 304 Not Modified :如果请求报文首部包含一些条件,例如:If-Match,If-Modified-Since,If-None-Match,If-Range,If-Unmodified-Since,如果不满足条件,则服务器会返回 304 状态码。
- 307 Temporary Redirect :临时重定向,与 302 的含义类似,但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。
- 400 Bad Request :请求报文中存在语法错误。
- 401 Unauthorized :该状态码表示发送的请求需要有认证信息(BASIC 认证、DIGEST 认证)。如果之前已进行过一次请求,则表示用户认证失败。
- 403 Forbidden :请求被拒绝,服务器端没有必要给出拒绝的详细理由。
- 404 Not Found
- 500 Internal Server Error :服务器正在执行请求时发生错误。
- 503 Service Unavilable :服务器暂时处于超负载或正在进行停机维护,现在无法处理请求。
Cookie 与 Session
Cookie
HTTP 协议是无状态的,主要是为了让 HTTP 协议尽可能简单,使得它能够处理大量事务。HTTP/1.1 引入 Cookie 来保存状态信息。
Cookie技术是客户端的解决方案,Cookie就是由服务器发给客户端的特殊信息,而这些信息以文本文件的方式存在客户端,然后客户端每次向服务器发送请求的时候会带上这些特殊的信息。
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据,它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。它用于告知服务端两个请求是否来自同一浏览器,并保持用户的登录状态。
Session
除了可以将用户信息通过 Cookie 存储在用户浏览器中,Session是另一种记录客户状态的机制,也可以利用 Session 存储在服务器端,存储在服务器端的信息更加安全。客户端浏览器访问服务器的时候,服务器把客户端的信息以某种形式记录在服务器上。
session的工作原理
- 创建Session
- 在创建了Session的同时,服务器会为改Session生成唯一的Session id
- 在Session被创建成功后,就可以调用Session相关的方法往Session 中增加内容
- 当客户端再次发送请求的时候,会将这个Session id 带上,服务器接受到请求之后就会依据Session id找到相应的Session
Cookie 与 Session 选择
-
存放的位置不同
Cookie 存储在浏览器中 Session 存在服务器中 -
存取的方式
Cookie 只能存储 ASCII 码字符串 而 Session 则可以存取任何类型的数据,因此在考虑数据复杂性时首选 Session; -
安全性(隐私策略)的不同
-
有效期上的不同
-
对服务器造成的压力不同
Cookie 存储在浏览器中,容易被恶意查看。如果非要将一些隐私数据存在 Cookie 中,可以将 Cookie 值进行加密,然后在服务器进行解密;
对于大型网站,如果用户所有的信息都存储在 Session 中,那么开销是非常大的,因此不建议将所有的用户信息都存储到 Session 中。
HTTPs
HTTPS使用SSL协议对Http传输数据进行了加密,保证安全。
HTTP 有以下安全性问题:
- 使用明文进行通信,内容可能会被窃听;
- 不验证通信方的身份,通信方的身份有可能遭遇伪装;
- 无法证明报文的完整性,报文有可能遭篡改。
加密
client/service 通过非对称加密生成秘钥,然后用这个秘钥对称加密传输数据。
密钥
密钥是一种参数,它是在使用密码cipher算法过程中输入的参数。同一个明文在相同的密码算法和不同的密钥计算下会产生不同的密文
对称密钥加密(DES,3DES,AES,RC5,RC6)
加密和解密使用同一密钥
- 优点:运算速度快;
- 缺点:密钥需要在通讯的两端共享无法安全地将密钥传输给通信方。
非对称密钥加密(RSA)
又称公开密钥加密(Public-Key Encryption),加密和解密使用不同的密钥。
公开密钥所有人都可以获得,通信发送方获得接收方的公开密钥后,就可以使用公开密钥进行加密,接收方收到通信内容后使用私有密钥解密
非对称密钥除了用来加密,还可以用来进行签名。因为私有密钥无法被其他人获取,因此通信发送方使用其私有密钥进行签名,通信接收方使用发送方的公开密钥对签名进行解密,就能判断这个签名是否正确。
- 优点:可以更安全地将公开密钥传输给通信发送方;
- 缺点:运算速度慢。
RSA加密简单过程
①服务端生成配对的公钥和私钥
②私钥保存在服务端,公钥发送给客户端
③客户端使用公钥加密明文传输给服务器
④服务器使用私钥解密密文得到明文
数字签名
数据在浏览器和服务器之间传输时,有可能在传输的过程中被第三方把内容替换了,那么如何保证数据是真实服务器发送的而不调包呢,同时如何保证传输的数据没有被人篡改呢?
将报文按双方约定的HASH算法计算得到一个固定位数的报文摘要。
在数学上保证:只要改动报文中任何一位,重新计算出来的报文摘要值就会与原先的值不相符。这就保证了报文的不可更改性。
数字证书
数字证书认证机构(CA,Certificate Authority)是客户端与服务器双方都可信赖的第三方机构。
服务器会把证书发送给客户端。客户端取得其中的公开密钥之后,先使 用数字签名进行验证,如果验证通过,就可以开始通信了