网络

OSI: TCP/IP

应用层 -- http smtp ftp

表示层 --

会话层 报文        进程到进程 提供同步点 断点续传 RPC,SQL 应用层

传输层 段 端到端 差错控制 流量控制 TCP,UDP 传输层(tcp,udp)

网络层 (路由层)包 packet 路由选择 ICMP IP ARP RARP IGMP 网络层(ip)

链路层 帧 frame 物理->数据 校验确认 反馈重发 HDLC MAC VLAN

物理层 bit          高低电平 IEE802.3 网络接口层

A:10.0.0.0 B:172.16.0.0 C:192.168.0.0

三次握手 四次挥手(在传输层)

Client                                   Server

sync_send 标志位Sync=1 发送序号:发送序号200->           

        <-标志位Sync=1 Ack=1  确认序号201  发送序号500   sync_RCVD

Established 标志位Ack=1 确认序号501  ->           Established

标志位 FIN 发送序号 200 ->

Fin_wait1

<-标志位 ACK 确认序号 201

FinWait2 closewait

<-标志位 FIN 发送序号500

Last_Ack

标志位 ACK 确认序号501->

Timewait

close close

Timewait:等待2MSL(一般1-4分钟,常用的有30s ,1m,2m)后closed 作用 可靠的实现tcp的终止  等待陈旧报文消失 TimeWait过多导致端口变少 申请socket困难

设置时长是2MSL的计时器. 超过2MSL的时候重发fin

closewait:服务端为了确保数据传送完设置的状态

三次握手:1.防止server端的资源耗尽 2,防止陈旧报文干扰 第二个入sync信号保证客户端的有效性

四次挥手:保证数据传输完整

套接字的含义:

  1)通信的目的地址;

  2)使用的传输层协议(如TCP、UDP);

  3)使用的端口号。

如何消除大量的Timewait :

1.改为长连接

2.增大端口范围

3.设置solinger

4.打开tcp一些参数

tcp怎么可靠:三次握手 四次挥手 超时重发  错误的重复的报文会丢弃  流量控制(滑动窗口协议) 拥塞控制  收到请求回应 对报文排序

tcp维持连接:keeplive 机制 两小时发送一个报文保证存活  heatbeat 应用层实现的小报文体 保证连接

syncflood 攻击  ddos攻击

land攻击 ack发给自身

sycwait1  sync队列  established后进入accept队列

connect accept send recv read write 都是阻塞函数

backlog 完成握手的队列大小 accept队列

TCP控制位:

ACK FIN SYN RST(重置)URG(紧急) PSH(传送)

Tcp和UDP的区别

1.重量轻量协议

2.tcp流udp报文

3.tcp端对端 udp有组播和广播

4.tcp有超时重发 差错控制

5.tcp会排序给应用层

6.tcp有流量控制和拥塞控制

7.基于链接三次握手和无链接

8.udp比tcp快

udp用于要求速度快可以有差错的情形 聊天视频 多播广播

udp快的原因:无需建立和维护链接 头部开销小8个字节tcp20个字节 没有流量控制和拥塞控制 没有超时重发机制 不需要回应

nagle算法(tcpNoDelay来决定是否使用这个算法):

将第一个字节发出取收到回值后将发送方缓冲的数据发出 在进行缓冲收到ack时再将缓冲的数据发出 当数据快而网络慢的时候提高利用率

粘包黏包:

原因:

使用nagle算法(nagle算法等待其他报文)

接受端接受不及时

解决:

关闭nagle算法

报文头中声明报文长度

在两段报文之间设置边界

做成定长

TCP的字段:

源端口(Source Port),目标端口(Destination Port) 各2字节 端口号可以使用0-65535

封包序号(Sequence Number) 4字节 记录包的顺序 让接收端将TCP数据重新组合起来

确认号(Acknowledge Number) 4字节 为了确认主机端确实有收到我们 client 端所送出的封包数据,我们 client 端当然希望能够收到主机方面的响应,那就是这个 Acknowledge Number 的用途了。

数据偏移(Data Offset)4比特 这个字段指出TCP报文段的数据起始处距离 TCP报文段的起始处有多远。 “数据偏移”的单位不是字节而是32bit字(4字节为计算单位)。

保留字段(Reserved) 占6比特

状态控制码(Code,Control Flag)标志位字段(U、A、P、R、S、F):占6比特。各 比特的含义如下:

URG:紧急比特(urgent),当URG=1时 传送高优先级数据

ACK:确认比特(Acknowledge)

PSH: 代表要求对方立即传送缓冲区内的其他对应封包,而无需等缓冲满了才送

RST: 必须释放连接,然后再重新建立运输连接。

SYN:同步比特(Synchronous),SYN置为1,就表示这是一个连接请求或连接接受报文,通常带有 SYN 标志的封包表示『主动』要连接到对方的意思。

FIM:关闭连接

滑动窗口(Window) 占2字节 窗口字段用来控制对方发送的数据量,可以告知对方目前本身有的缓冲器容量(Receive Buffer) 还可以接收封包。用来告知对方自己缓冲区的大小

TCP校验和(Checksum)  占2字节

紧急指针(Urgent Pointer)  占2字节

HTTP协议

http://127.0.0.1:8888?xxx=xxx  url

Http请求协议

请求行:

GET  ip号主机号    http1.1/http1.0  post put trace head delete option

请求头:

Host 服务器ipport

User-Agent发送的程序名称

Connection 链接相关的属性

Acceept_Charset 服务端的编码格式

Accept-Encoding 数据压缩格式

Accept-Language 服务端可发送的语言

Refer:服务器从哪个页面链接过来的 refer包含恶意网址的地址 防止CSRF攻击

正文

Http返回协议

200 ip主机号  http1.1/1.0  100正在传输 200ok  301永久重定向 302临时重定向 304缓存 401密码保护 403拒绝  404服务器上没有 500 服务端错误

Server服务器的软件名称和版本

Content_Length

Content_Type

Content_Charset

Content_Language

Location 重新定向的URI

正文

通用的报文Date Connection cache-Control 控制

Last-Modified 发送最后修改时间        304 关于缓存

Etag  类似资源的标识符 判定资源内容是否变化 优先级高于Last_Modfied

Http1.0和Http1.1的区别:

1.Http1.1默认KeepLive长连接

2.Http1.1有range请求头 可以传送块 分块传输

3.http1.1有Host域同一个IP地址可有多个主机

4.Http1.1有100状态码 是否可以结合搜冗长的请求

Get和Post的区别:

1.Get请求安全 多次请求返回相同结果 Post不是安全和幂等的

2.get传输的数据在?后k,v形式 长度浏览器决定 明文传输 浏览器有缓存数据

  post在请求体中 数据长度服务器处理能力决定

如何保持状态(会话跟踪):

1. Cookie

2. Session

3. Url重写 url后写sessionid

4. 隐藏表单域:隐藏域是用来收集或发送信息的不可见元素,对于网页的访问者来说,隐藏域是看不见的。当表单被提交时,隐藏域就会将信息用你设置时定义的名称和值发送到服务器上。

5.webstorge H5新特性

http长连接优缺点:

优点:

1.节省建立链接cpu内存

2.减少网络拥塞

缺点:

1.维护链接浪费资源

http问题:

1.明文传输不加密

2.没有完整性校验

3.没有身份验证

TLS流程:

1.ClientHello:向服务端发送ClientHello Random1 客户端加密算法 SSLVersion

2.ServerHello:确定加密算法,随机数Random2

3.Certificate: 将证书发送给客户端 让各客户端取出证书中公钥 可以要求客户端提交证书

4.ServerHelloDone

5.Certificate Verify 验证通过后取出证书中的服务端公钥,再生成一个随机数 Random3,再用服务端公钥非对称加密 Random3 生成 PreMaster Key。

6.3个随机数和对称加密算法生成一份密钥

流程见图

用到了:

1.对称加密算法 2.非对称加密算法 3.完整型算法 4.数字证书CA

http和socket区别:

1.socket有udp

2.socket可以反向推送 服务器向客户端推送消息

3.socket解析字段少

CSRF;盗用你的身份发送恶意请求

防御方法:

1.清除认证cookie

2,在post中提供一个不可预测的参数

数据加密

1.单向散列算法:

md5 sha1 sha256

2.对称加密算法:

des aes

3. 非对称:RSA

Cookie和Session的区别:

1.cookie在客户端 session在服务器

2.cookie有泄漏风险 session没有

3.session占用服务器资源 cookie有大小和个数的限制

重要信息在session中

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,658评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,482评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,213评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,395评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,487评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,523评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,525评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,300评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,753评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,048评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,223评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,905评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,541评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,168评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,417评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,094评论 2 365
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,088评论 2 352

推荐阅读更多精彩内容