一、TCP/IP
TCP/IP协议组：解决数据如何在网络中传输
网络层（IP协议、ICMP、ARP、RARP、BOOTP）
传输层（TCP、UDP）
应用层（FTP、HTTP、TELNET、SMTP、DNS 应用层TFTP对应传输层UDP）
二、.Socket
2.1概念：Socket是对TCP/IP协议的封装，Socket是实现传输层协议的编程API，可以是TCP或UDP。网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。应用程序通常通过socket发送/应答、网络请求，即网络上的请求是通过Socket来建立连接然后互相通信。
Socke套接字是通信基石，是支持TCP/IP网络通信的基本操作单元，是网络通信中端点的抽象表示，包含网络通信必须的五种信息：连接使用的协议、本地/远程主机的IP地址、本地/远程进程的协议端口。应用层和传输层数据通信时，多个TCP连接或多个应程序进程可能需通过同一TCP协议端口传输数据。能通过Socket接口区分来自不同应用程序进程或网络连接的通信，实现数据传输并发服务。
2.2建立socket连接
socket连接通常就是TCP连接，一旦建立即可相互发送数据直到连接断开。理论上不会主动断掉连接，但实际需穿越多个中间节点如路由器、网关、防火墙等会使连接断开，非活跃连接会被关闭以释放资源，故Socket需要轮询即发送心跳信息，告诉网络该连接处于活跃状态。建立Socket连接：至少一对套接字ClientSocket和ServerSocket。
2.2.1连接过程：
服务器监听（不定位具体客户端套接字，等待连接请求、实时监控网状）、客户端请求（必指出服务器端套接字地址和端口号，然后提出连接请求）、连接确认（服务器端套接字监听或接收到连接请求就响应，建立新线程，发送服端描述给客端，一旦客端确认了就正式建立连接，而服端继续处于监听状态，继续接收其他客端连接请求）
2.3 Socket传输的特点：
优点：传输数据字节级、可自定义、数据量小
时间短性能高、实时交互、可加密安全性强
缺点：需对传输数据解析成应用数据、对开发水平要求高、相较于http协议传输增加了开发量
很多情况下服端主动向客端推送数据，保持客端与服端的实时与同步，此时若是Socket连接，可直接将数据传给客端
2.4使用范围：
对传输速度、安全性、实时交互、费用等要求高的应用，如网游、手机应用、银行内部交互等。
三、FTP
FTP文件传输协议是TCP/IP网络上两个计算机传送文件的协议，最早使用的协议之一，属于网络协议组应用层。客户机给服务器发命令下载/上传文件、创建/改变服务器上目录。
四、Http超文本传输协议hypertext transport protocol
4.1.请求/响应报文
请求行：包含方法字段，URL，协议版本
首部字段名：值。以keyvalue的形式组装在一起 回车换行 由多个首部字段名构成首部字段区域
请求实体主体：post带，get不带
响应报文
响应行：版本，状态码，短语
首部字段区域
实体主体
4.2 http常见请求方式有哪些？
GET、POST、DELETE、OPTIONS、PUT、HEAD
4.3.GET与POST的共同点和区别？
共同点：POST和GET都是向服务器提交数据，并且都会从服务器获取数据。
1、传送方式：get通过地址栏传输，post通过报文传输。post(请求体里)、get(请求参数直接跟在url后面)
2、传送长度：get参数有长度限制2048个字符（受限于url长度），而post无限制
3.从语义的角度来回答
GET获取资源，安全（不引起Server端数据状态变化 get,head,options）、幂等(同一请求方法执行1和多次效果完全相同put,delete)，可缓存（代理服务器可缓存，get,head）
POST处理资源，非安全、非幂等，不可缓存
4、GET和POST还有一个重大区别，简单的说：
GET产生一个TCP数据包；POST产生两个TCP数据包
详细的说：
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。
也就是说，GET只需要汽车跑一趟就把货送到了，而POST得跑两趟，第一趟，先去和服务器打个招呼“嗨，我等下要送一批货来，你们打开门迎接我”，然后再回头把货送过去。
因为POST需要两步，时间上消耗的要多一点，看起来GET比POST更有效。因此Yahoo团队有推荐用GET替换POST来优化网站性能。但这是一个坑！跳入需谨慎。为什么？
-
GET与POST都有自己的语义，不能随便混用。
-
据研究，在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。
-
并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。
1、get方式的安全性较Post方式要差些，包含机密信息的话，建议用Post数据提交方式；
2、在做数据查询时，建议用Get方式；而在做数据添加、修改或删除时，建议用Post方式；
案例：一般情况下，登录的时候都是用的POST传输，涉及到密码传输，而页面查询的时候，如文章id查询文章，用get 地址栏的链接为：article.php?id=11，用post查询地址栏链接为：article.php， 不会将传输的数据展现出来。
遇到过的问题：如服务器端设置只允许Get请求，浏览器能打开是Get请求访问，而手机端如果请求方式是Post就会报错。结论：电脑端与手机端请求不一样，配置的路由规则可能都不一样；
4.4.连接建立流程
TCP连接的三次握手 同步包
1.建立连接时客户端发送syn = j包到服务器，并进入syn_send状态，等待服务器确认，同步序列编号(Synchronize Sequence Numbers)
2.服务端收到syn包，必须确认客户端的syn(ack=j+1),同时自己也发送一个syn包（syn=k） 即syn+ack，此时服务器进入syn_recv状态
3.客户端收到syn+ack包，向服务器发送确认包ack=k+1,发送完毕后客户端和服务器端进入established(tcp连接成功)状态，完成三次握手
四次挥手 终止报文 确认报文
1.客户端发送一个FIN（finish数据段，与syn一样，每个占用一个序号）用来关闭客户端到服务端的数据传送
2.服务端收到这个FIN后回发一个ack,确认序号为收到的序号+1
3.服务端关闭与客户端的连接，某一时机服务器端发送一个FIN给客户端
4.客户端回发ack报文确认，并将确认序号设置为收到序号+1
4.5 HTTP的组成和特点
http 请求由三部分组成，分别是：请求行、消息报头、请求正文
特点
1.支持客户/服务器模式。
2.简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有 GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于 HTTP 协议简单，使得 HTTP 服务器的程序规模小，因而通信速度很快。
3.灵活：HTTP 允许传输任意类型的数据对象。正在传输的类型由 Content-Type 加以标记。
4.无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。
5.无状态：HTTP 协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。
4.6http状态码有哪些？分别代表什么意思？
100-199 用于指定客户端应相应的某些动作。
200-299 用于表示请求成功。
300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
400-499 用于指出客户端的错误。
400 语义有误，当前请求无法被服务器理解。
401 当前请求需要用户验证
403 服务器已经理解请求，但是拒绝执行它
500-599 用于支持服务器错误。
503 – 服务不可用。
五、Https与网络安全
5.1概念：
HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为 HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输，https有效避免接口数据在传输中被攻击。
TLS（Transport Layer Security，传输层安全）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999 年从 3.1 开始被 IETF 标准化并改名，发展至今已经有 TLS 1.0、TLS 1.1、TLS 1.2 三个版本。SSL3.0 和 TLS1.0 由于存在安全漏洞，已经很少被使用到。TLS 1.3 改动会比较大，目前还在草案阶段，目前使用最广泛的是 TLS 1.1、TLS 1.2。
5.2 iOS配置HTTPS支持苹果ATS：
（2017年1月1日起，苹果AppStore中的所有App都必须启用 App Transport Security(ATS)安全功能。App TransportSecurity(应用程序安全传输)，简称 ATS，是苹果在 iOS 9 中首次推出的一项隐私安全保护功能，启用ATS后，它会屏蔽明文HTTP资源加载，强制App通过HTTPS连接网络服务，通过传输加密保障用户数据安全。ATS在 iOS 9 中是默认开启的，但开发者仍然可以选择关闭 ATS，让自己的应用通过 HTTP 连接传输数据。但从2017年1月1日起，这招将行不通了，所有提交到 App Store 的App必须强制开启 ATS。）
所访问请求是Http类型时，在info.plist里添加 AppTransportSecurity（Dictionary类型）底下添加AllowArbitraryLoads（Boolean类型）设置成YES 可以直接用文本编辑器打开添加也可用Xcode添加。一劳永逸的方法是让服务端升级使用TLS 1.2 SSL 加密请求的Https协议。
5.3项目中网络层如何做安全处理？
1）尽量用https
https能过滤掉大部分安全问题但https在证书申请、服务器配置、性能优化、客户端配置上都需要时间和精力，故容易被缺乏安全意识的开发人员跳过，如果没精力优化性能，至少在注册登录这部分对业务性能要求较低的模块启用https.
2)不要传输明文密码
最好客户端不做任何密码相关的存储，仅存储token进行下一次认证，而且token需要设置有效期，使用refresh token去申请新token。服务器端或网络传输过程要避免明文密码，最好用hash值
3)post并不比get安全
两者都是明文传输，参数在QueryString或body没任何安全上的差别。在http环境，都需要做加密和签名处理
4）不要用301跳转
301跳转容易被http劫持攻击。移动端因为用户看不到浏览器地址，无法察觉到被重定向了别的地址，故比在桌面端使用301跳转更危险。如果一定要用301跳转，应确保跳转发生在https环境下而且https做了证书绑定
5）http请求都带上MAC
所有客户端发出的请求，无论是查询还是写操作，都带上MAC（Message AuthenticationCode）。MAC不但能保证请求没有被篡改（Integrity），还能保证请求确实来自你的合法客户端（Signing）。当然前提是你客户端的key没有被泄漏，如何保证客户端key的安全是另一个话题。MAC值的计算可以简单的处理为hash（request params＋key）。带上MAC之后，服务器就可以过滤掉绝大部分的非法请求。MAC虽然带有签名的功能，和RSA证书的电子签名方式却不一样，原因是MAC签名和签名验证使用的是同一个key，而RSA是使用私钥签名，公钥验证，MAC的签名并不具备法律效应。
6）http请求使用临时密钥
高延迟网络环境下，不经优化的https体验明显不如http.在不具备https条件或对网络性能要求较高且缺乏https优化经验的场景下，http的流量也应该使用AES进行加密。AES的密钥可以由客户端来临时生成，不过这个临时的AES key需要使用服务器的公钥进行加密，确保只有自己的服务器才能解开这个请求的信息，当然服务器的response也需要使用同样的AES key进行加密。由于http的应用场景都是由客户端发起，服务器响应，所以这种由客户端单方生成密钥的方式可以一定程度上便捷的保证通信安全
7）URL加密、数据传输加密
URL加密处理，防止反编译导致接口信息被静态分析；数据传输加密，对客户端传输数据提供有效加密方案，防止网络接口拦截。
8）AES加密使用CBC模式
AES即Advanced Encryption Standard高级加密标准的缩写在密码学中又称Rijndael加密法，是美国联邦*采用的一种区块加密标准。不用ECB模式且记得设置初始化变量，每个block加密前要和上个block的密文进行运算。
六、传输层TCP/UDP
TCP连接的三次握手 同步包
1.建立连接时客户端发送syn = j包到服务器，并进入syn_send状态，等待服务器确认，同步序列编号(Synchronize Sequence Numbers)
2.服务端收到syn包，必须确认客户端的syn(ack=j+1),同时自己也发送一个syn包（syn=k） 即syn+ack，此时服务器进入syn_recv状态
3.客户端收到syn+ack包，向服务器发送确认包ack=k+1,发送完毕后客户端和服务器端进入established(tcp连接成功)状态，完成三次握手
四次挥手 终止报文 确认报文
1.客户端发送一个FIN（finish数据段，与syn一样，每个占用一个序号）用来关闭客户端到服务端的数据传送
2.服务端收到这个FIN后回发一个ack,确认序号为收到的序号+1
3.服务端关闭与客户端的连接，某一时机服务器端发送一个FIN给客户端
4.客户端回发ack报文确认，并将确认序号设置为收到序号+1
为什么是3次握手而不是2次？
C向Ｓ发送同步报文在网络路由传输过程中发生了超时，C端会启用超时重传策略，当Ｓ收到同步报文后，若只有2次握手，连接就建立了。此时Ｓ端收到了超时的那个同步报文，就会以为C又需要建立连接，对于Ｓ来说相当于发生了两次tcp连接。而3次握手，经过一定时间后，客户端并没有再给服务器端再发送确认报文，这样服务器端就知道并不是再次建立连接。
七、网络层IP、DNS解析
7.1DNS解析概念：
域名到IP地址的映射。DNS解析请求采用udp数据报，而且是明文的。
7.2DNS解析查询方式：
递归查询（我去给你问一下）、迭代查询（我告诉你谁可能知道）
本地 根域 * 权限DNS
7.3 DNS劫持
7.3.1概念：
客户端向DNS服务器发送一个域名，这个时候如果有一个钓鱼的DNS，它就会劫持这个域名，然后返回给客户端一个错误的IP，那这个客户端就拿到这个错误的IP去访问了一个错误的服务器地址。
7.3.2 DNS劫持与HTTP有关吗？
DNS解析是发生在HTTP建立连接之前， DNS解析请求使用udp数据报访问端口号53，所以DNS劫持与HTTP没有任何关系
7.3.3怎么解决DNS劫持？
httpDNS 实际上是使用HTTP协议，向DNS服务器的80端口进行请求。不产生正常的DNS解析，不存在DNS劫持问题。
长连接：给客户端提供一个长连通道，长连通道通过内网专线向API服务器发送HTTP请求。
7.4 DNS解析转发
当客户端在询问本地DNS某一域名对应IP地址，比如用的是某某移动的DNS,这时候这个DNS服务器就会解析域名，还有的时候有一些小的运营商不遵守协议规范,。做节省资源，会把我们的这个域名解析请求转发给其他的某个电信的DNS服务器。让他来帮助解析某某移动电视的域名到IP地址的解析转发。某某电信的DNS会向权威的DNS请求解析域名对应的IP地址。权威DNS会根据不同运营商的请求情况。针对不同网络情况的流量调度分发。比如如果是某某移动。请求的对应IP地址2.2.2，某某电信请求对应的IP地址是3.3.3。最终返回给默默移动的DNS是3.3.3，跨网访问的过程，请求缓慢效率问题。
八、Session/Cookie
8.1Cookie主要用来记录用户状态，区分用户状态，状态保存在客户端。
客户端发送的cookie，在HTTP请求报文的cookie首部字段当中，服务器端设置的HTTP响应报文的SetCookie来向客户端传递cookie内容。
8.1.1怎样修改cookie?
新cookie覆盖旧cookie
覆盖原则：name,path,domain需要与原cookie一致。
8.1.2怎样删除cookie？
覆盖原则同上
设置cookie的expires等于过去的一个时间点或者maxAge等于0
8.1.3怎样保证cookie的安全？
8.2 Session记录用户状态,区分用用户,状态存放在服务器端。
Session依赖于cookie机制实现。
8.2.1 Session工作流程
客户端向服务器端发送请求,服务器端记录用户状态并生成sessionid,通过HTTP的响应头部Set-Cookie把这个sessionid传给客户端，客户端收到响应以后发送信息，把这个sessionid放到请求头部字段cookie里面传给服务器端，服务器通过这个sessionid识别用户。