应用层
我们程序员写的一个个解决我们实际问题, 满足我们日常需求的网络程序, 都是在应用层
协议
序列化与反序列化
定义结构体来表示我们需要交互的信息;
发送数据时将这个结构体按照一个规则转换成字符串, 接收到数据的时候再按照相同的规则把字符串转化回结构体;
这个过程叫做 “序列化” 和 “反序列化”
通俗解释：
我们在发送信息的时候，我们需要发送一个结构体
结构体包括：昵称，头像，信息，时间，，，，
我们需要将其转化成为一段字符串“昵称：xxx，头像：xxx，信息：xxx，时间：xxx”（序列化）
发送过去后，我们需要将这段字符串重新转化为结构体（反序列化）
为什么要进行序列化和反序列化？
1.为了应用层网络通信的方便
2.为了方便上层进行使用内部成员，将应用和网络进行了解耦
补充解释：
1.结构化的数据，是不便于网络传输的
2.字符串便于网络传输
3.结构化的数据，本质就是协议的表现
实现一个计算器
目的：通过代码和应用层进行对比
1无序列化和反序列化的计算器
Protocol.hpp
//客户端和服务器通信时的协议内容---自己定协议
#pragma once
#include <iostream>
#include <string>
#include <jsoncpp/json/json.h>
using namespace std;
//定制协议的过程，目前就是定制结构化数据的过程
//请求格式
//我们自己定义的协议，client和server都必须遵守！这就叫做自定义协议
typedef struct request
{
int x;
int y;
char op;//支持"+-*/"
}request_t;
//响应格式
typedef struct response
{
int code;//server运算完毕的计算状态：code（0：success），code（-1：div 0）。。。
int result;//计算结果，能否区分是正常的计算结果，还是异常的退出结果
}response_t;
Sock.hpp
为防止文章内容过多，这里只写一份Sock.hpp
#pragma once
#include<iostream>
#include<string>
#include<cstring>
#include<cstdlib>
#include<sys/socket.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
using namespace std;
class Sock
{
public:
static int Socket()
{
int sock = socket(AF_INET,SOCK_STREAM,0);
if(sock < 0)
{
cerr<<"socket error"<<endl;
exit(2);
}
return sock;
}
static void Bind(int sock,uint16_t port)
{
struct sockaddr_in local;
memset(&local,0,sizeof(local));
local.sin_family = AF_INET;
local.sin_port = htons(port);
local.sin_addr.s_addr = INADDR_ANY;
if(bind(sock,(struct sockaddr*)&local,sizeof(local))<0)
{
cerr<<"bind error!"<<endl;
exit(3);
}
}
static void Listen(int sock)
{
if(listen(sock,5)<0)
{
cerr<<"listen error!"<<endl;
exit(4);
}
}
static int Accept(int sock)
{
struct sockaddr_in peer;
socklen_t len = sizeof(peer);
int fd = accept(sock,(struct sockaddr*)&peer,&len);
if(fd>0)
{
return fd;
}
else return -1;
}
static void Connect(int sock,std::string ip,uint16_t port)
{
struct sockaddr_in server;
memset(&server,0,sizeof(server));
server.sin_family = AF_INET;
server.sin_port = htons(port);
server.sin_addr.s_addr = inet_addr(ip.c_str());
if(connect(sock,(struct sockaddr*)&server,sizeof(server)) == 0)
{
cout<<"connect success!"<<endl;
}
else{
cout<<"connect failed!"<<endl;
exit(5);
}
}
};
Makefile
.PHONY:all
all:CalClient CalServer
CalClient:CalClient.cc
g++ -o $@ $^ -std=c++11
CalServer:CalServer.cc
g++ -o $@ $^ -std=c++11 -lpthread
.PHONY:clean
clean:
rm -rf CalClient CalServer
CalServer.cc
#include "Protocol.hpp" //协议功能
#include "Sock.hpp" //网络功能
#include <pthread.h>
static void Usage(string proc)
{
std::cout << "Usage" << proc << "port" << std::endl;
exit(1);
}
void *HandlerRequest(void *args)
{
int sock = *(int *)args;
delete (int *)args;
pthread_detach(pthread_self());
// version 1 原生方法，没有明显的序列化和反序列化的过程
//业务逻辑,做一个短服务
// request->分析处理->构建response->sent(response)->close(sock)
// 1.读取请求
request_t req;
ssize_t s = read(sock, &req, sizeof(req));
if (s == sizeof(req))
{
//读取到了完整的请求，待定
// req.x,req.y,req.op;
// 2.分析请求 && 3.计算结果
// 4.构建响应，并进行返回
response_t resp = {0, 0};
switch (req.op)
{
case '+':
resp.result = req.x + req.y;
break;
case '-':
resp.result = req.x - req.y;
break;
case '*':
resp.result = req.x * req.y;
break;
case '/':
if (req.y == 0)
resp.code = -1; //代表除零
else
resp.result = req.x / req.y;
break;
case '%':
if (req.y == 0)
resp.code = -2; //代表模0
else
resp.result = req.x / req.y;
break;
default:
resp.code = -1; //代表请求方法异常
break;
}
cout << "request:" << req.x << req.op << req.y <<" = "<<resp.result<< endl;
write(sock, &resp, sizeof(resp));
cout<<"响应服务结束"<<endl;
}
// 5.关闭链接
close(sock);
}
// ./CalServer port
int main(int argc, char *argv[])
{
if (argc != 2)
Usage(argv[0]);
uint16_t port = atoi(argv[1]);
int listen_sock = Sock::Socket();
Sock::Bind(listen_sock, port);
Sock::Listen(listen_sock);
for (;;)
{
int sock = Sock::Accept(listen_sock);
if (sock >= 0)
{
cout << "get a new client..." << endl;
int *pram = new int(sock);
pthread_t tid;
pthread_create(&tid, nullptr, HandlerRequest, pram);
}
}
return 0;
}
CalClient.cc
#include "Protocol.hpp"
#include "Sock.hpp"
void Usage(string porc)
{
cout << "Usage: " << porc << "server_ip server_port" << endl;
}
// ./CalClient server_ip server_port
int main(int argc, char *argv[])
{
if (argc != 3)
{
Usage(argv[0]);
exit(1);
}
int sock = Sock::Socket();
Sock::Connect(sock, argv[1], atoi(argv[2]));
// while (true)
// {
//业务逻辑
request_t req;
memset(&req, 0, sizeof(req));
cout << "Please Enter Data One#";
cin >> req.x;
cout << "Please Enter Data Teo#";
cin >> req.y;
cout << "Please Enter operator#";
cin >> req.op;
ssize_t s = write(sock, &req, sizeof(req));
response_t resp;
s = read(sock, &resp, sizeof(resp));
if (s == sizeof(resp)) //读到完整报文
{
cout << "code[0:success]:" << resp.code << endl;
cout << "result: " << resp.result << endl;
}
// }
return 0;
}
2.含序列化和反序列化（在1的基础上增加代码）
安装json
sudo yum install -y jsoncpp-devel
原理：
#include<iostream>
#include<string>
#include<jsoncpp/json/json.h>
typedef struct request
{
int x;
int y;
char op;//支持"+-*/"
}request_t;
int main()
{
//反序列化
std::string json_string = R"({"datax":10,"datay":20,"operator":42})";
Json::Reader reader;
Json::Value root;
reader.parse(json_string,root);
request_t req;
req.x = root["datax"].asInt();
req.y = root["datay"].asInt();
req.op = (char)root["operator"].asUInt();
std::cout<<req.x<<req.y<<req.op<<std::endl;
//序列化的过程
// request_t req = {10,20,'*'};
// Json::Value root;//可以承装任何对象，json是一种kv式的序列化方案
// root["datax"] = req.x;
// root["datay"] = req.y;
// root["operator"] = req.op;
// //FastWriter,StyledWriter
// // Json::StyledWriter writer;
// Json::FastWriter writer;
// std::string Json_string = writer.write(root);
// std::cout<<Json_string<<std::endl;
return 0;
}
//g++ test_json.cc -std=c++11 -ljsoncpp
Protocol.hpp
//客户端和服务器通信时的协议内容---自己定协议
#pragma once
#include <iostream>
#include <string>
#include <jsoncpp/json/json.h>
using namespace std;
//定制协议的过程，目前就是定制结构化数据的过程
//请求格式
//我们自己定义的协议，client和server都必须遵守！这就叫做自定义协议
typedef struct request
{
int x;
int y;
char op;//支持"+-*/"
}request_t;
//响应格式
typedef struct response
{
int code;//server运算完毕的计算状态：code（0：success），code（-1：div 0）。。。
int result;//计算结果，能否区分是正常的计算结果，还是异常的退出结果
}response_t;
// 代码问题：
// 我们定义了这么多，
// 例如： int x, char op, int y,这就是我们的自定义协议
//
// 正常通信时，
// 因为版本的迭代，服务器的升级，结构体内每个字段的大小，内存对齐的方式是什么样子,
// 会导致协议的改变，从而导致这个代码出现问题
//
// 根本原因：少了序列化和反序列化的步骤
// 序列化和反序列化有很多的方法
// sudo yum install -y jsoncpp-devel
//序列化是：将结构化的数据转化为字符串
//request_t -> string
std::string SerializeRequest(const request_t &req)
{
//序列化的过程
Json::Value root;//可以承装任何对象，json是一种kv式的序列化方案
root["datax"] = req.x;
root["datay"] = req.y;
root["operator"] = req.op;
//FastWriter,StyledWriter
// Json::StyledWriter writer;
Json::FastWriter writer;
std::string json_string = writer.write(root);
return json_string;
}
//反序列化
//string -> request_t
void DeserializeRequest(const std::string &json_string,request_t &out)
{
//反序列化
Json::Reader reader;
Json::Value root;
reader.parse(json_string,root);
out.x = root["datax"].asInt();
out.y = root["datay"].asInt();
out.op = (char)root["operator"].asUInt();
}
//response
std::string SerializeResponse(const response_t &resp)
{
Json::Value root;
root["code"] = resp.code;
root["result"] = resp.result;
Json::FastWriter writer;
std::string res = writer.write(root);
return res;
}
void DeserializeResponse(const std::string &json_string,response_t &out)
{
Json::Reader reader;
Json::Value root;
reader.parse(json_string,root);
out.code = root["code"].asInt();
out.result = root["result"].asInt();
}
Makefile
.PHONY:all
all:CalClient CalServer
CalClient:CalClient.cc
g++ -o $@ $^ -std=c++11 -ljsoncpp
CalServer:CalServer.cc
g++ -o $@ $^ -std=c++11 -lpthread -ljsoncpp
.PHONY:clean
clean:
rm -rf CalClient CalServer
CalServer.cc
#include "Protocol.hpp" //协议功能
#include "Sock.hpp" //网络功能
#include <pthread.h>
static void Usage(string proc)
{
std::cout << "Usage" << proc << "port" << std::endl;
exit(1);
}
void *HandlerRequest(void *args)
{
int sock = *(int *)args;
delete (int *)args;
pthread_detach(pthread_self());
// version 1 原生方法，没有明显的序列化和反序列化的过程
//业务逻辑,做一个短服务
// request->分析处理->构建response->sent(response)->close(sock)
// 1.读取请求
char buffer[1024];
request_t req;
ssize_t s = read(sock, buffer, sizeof(buffer) - 1);
if (s > 0) //读取成功
{
buffer[s] = 0;
std::cout<<"get a new request: "<<buffer<<std::endl;
std::string str = buffer;
DeserializeRequest(str, req);//反序列化请求
// request_t req;
// ssize_t s = read(sock, &req, sizeof(req));
// if (s == sizeof(req))
// {
//读取到了完整的请求，待定
// req.x,req.y,req.op;
// 2.分析请求 && 3.计算结果
// 4.构建响应，并进行返回
response_t resp = {0, 0};
switch (req.op)
{
case '+':
resp.result = req.x + req.y;
break;
case '-':
resp.result = req.x - req.y;
break;
case '*':
resp.result = req.x * req.y;
break;
case '/':
if (req.y == 0)
resp.code = -1; //代表除零
else
resp.result = req.x / req.y;
break;
case '%':
if (req.y == 0)
resp.code = -2; //代表模0
else
resp.result = req.x / req.y;
break;
default:
resp.code = -1; //代表请求方法异常
break;
}
cout << "request:" << req.x << req.op << req.y << " = " << resp.result << endl;
// write(sock, &resp, sizeof(resp));
std::string send_string = SerializeResponse(resp);//序列化之后的字符串
write(sock, &send_string, send_string.size());
cout << "服务结束: "<<send_string << endl;
// }
}
// 5.关闭链接
close(sock);
}
// ./CalServer port
int main(int argc, char *argv[])
{
if (argc != 2)
Usage(argv[0]);
uint16_t port = atoi(argv[1]);
int listen_sock = Sock::Socket();
Sock::Bind(listen_sock, port);
Sock::Listen(listen_sock);
for (;;)
{
int sock = Sock::Accept(listen_sock);
if (sock >= 0)
{
cout << "get a new client..." << endl;
int *pram = new int(sock);
pthread_t tid;
pthread_create(&tid, nullptr, HandlerRequest, pram);
}
}
return 0;
}
CalClient.cc
#include "Protocol.hpp"
#include "Sock.hpp"
void Usage(string porc)
{
cout << "Usage: " << porc << "server_ip server_port" << endl;
}
// ./CalClient server_ip server_port
int main(int argc, char *argv[])
{
if (argc != 3)
{
Usage(argv[0]);
exit(1);
}
int sock = Sock::Socket();
Sock::Connect(sock, argv[1], atoi(argv[2]));
// while (true)
// {
//业务逻辑
request_t req;
memset(&req, 0, sizeof(req));
cout << "Please Enter Data One#";
cin >> req.x;
cout << "Please Enter Data Teo#";
cin >> req.y;
cout << "Please Enter operator#";
cin >> req.op;
std::string json_string = SerializeRequest(req);
// ssize_t s = write(sock, &req, sizeof(req));
ssize_t s = write(sock, json_string.c_str(), json_string.size());
char buffer[1024];
s = read(sock, buffer, sizeof(buffer) - 1);
if (s > 0)
{
response_t resp;
buffer[s] = 0;
std::string str = buffer;
DeserializeResponse(str, resp);
cout << "code[0:success]:" << resp.code << endl;
cout << "result: " << resp.result << endl;
}
// response_t resp;
// s = read(sock, &resp, sizeof(resp));
// if (s == sizeof(resp)) //读到完整报文
// {
// cout << "code[0:success]:" << resp.code << endl;
// cout << "result: " << resp.result << endl;
// }
// }
return 0;
}
3.总结
我们写的 CS 模式的在线版本计算器，本身就是一个应用层网络服务
基本通信代码是我们自己写的；（会话层）
序列和反序列化是我们用组件完成的；（表示层）
业务逻辑是我们自己定的；（应用层）
请求结果格式，code含义等约定是我们自己做的。（应用层）
HTTP协议（超文本传输协议）
http协议，本质上，在定位上和我们写的计算器，没有区别，都是应用层协议
1.网络通信
2.序列化和反序列化
3.协议细节
http协议内部，http会自己实现！
认识URL（网址）
平时我们俗称的 “网址” 其实就是说的 URL
网址：定位网络资源的一种方式
我们请求的图片，html，js，视频，音频，标签，文档，，，这些统称为“资源”
服务器后台，是用linux做的
IP+port 唯一的确定一个进程
但是我们无法唯一的确认一个资源！
公网IP地址是唯一确认一台主机的，而我们所谓的网络“资源”都一定是存在于网络中的一台Linux机器上！Linux或者传统的OS，保存资源的方式，都是以文件的方式保存的。
单Linux系统，标识一个唯一资源的方式，通过路径！
所以：IP+Linux路径，就可以唯一的确认一个网络资源！
IP->通常是以域名的方式呈现的。
路径可以通过目录名+/ 确认。
urlencode和urldecode（了解）
像 / ? : 等这样的字符, 已经被url当做特殊意义理解了. 因此这些字符不能随意出现.
比如, 某个参数中需要带有这些特殊字符, 就必须先对特殊字符进行转义.
转义的规则如下:
将需要转码的字符转为16进制，然后从右到左，取4位(不足4位直接处理)，每2位做一位，前面加上%，编码成%XY格式
“+” 被转义成了 “%2B”
urldecode就是urlencode的逆过程;
urlencode编码和urldecode解码
HTTP协议宏观认识
简化认识：
无论是请求还是响应，基本上HTTP都是按照行（\n）为单位进行构建请求或者响应的！
无论是请求还是响应，几乎都是由3或者4部分组成
如何理解普通用户的上网行为！-》主要是为了简单！
1.从目标服务器拿到你要的资源
2.向目标服务器上传你的数据
即：IO
思考：
1.http如何解包，如何封装，如何分用？
请求行+请求报头+空行 = http报头
请求正文 = http有效载荷
状态行+响应报头+空行 = http响应报头
响应正文 = http有效载荷
空行：特殊字符
用空行 将 长字符串一切为二
解包封装：根据空行来进行分割，然后解包和封装
分用（将你的有效载荷交给谁？）：不是http解决的，是具体的应用代码解决的，http需要有接口来帮助上层获取参数
2.http请求或者响应，是如何被读取的？
3.http请求时如何发送的？
–>http request和http response被如何看待？
可以将请求和响应整体看作一个大的字符串！
http操作
#include "Sock.hpp"
#include<pthread.h>
void Usage(std::string proc)
{
std::cout<< "Usage"<<proc<<"prot"<<endl;
}
void *HandlerHttpRequest(void *args)
{
int sock = *(int*)args;
delete (int*)args;
pthread_detach(pthread_self());
#define SIZE 1024*10
char buffer[SIZE];
memset(buffer,0,sizeof(buffer));
//recv是网络读取专门定制的函数
ssize_t s = recv(sock,buffer,sizeof(buffer),0);
if(s>0)
{
buffer[s]=0;
std::cout<<"查看http请求格式:"<<buffer; //for test
std::string http_response = "http/1.0 200 ok\n";
http_response +="Content-Type: text/plain\n";//text/plain，正文是普通的文本
http_response +="\n";//空行，用来区别报头和有效载荷
http_response += "hello sakeww!";
send(sock,http_response.c_str(),http_response.size(),0);
}
close(sock);
}
int main(int argc,char *argv[])
{
if(argc!=2)
{
Usage(argv[0]);
exit(1);
}
uint16_t port = atoi(argv[1]);
int listen_sock = Sock::Socket();
Sock::Bind(listen_sock,port);
Sock::Listen(listen_sock);
for(;;)
{
int sock = Sock::Accept(listen_sock);
if(sock>0)//成功
{
pthread_t tid;
int *pram = new int(sock);
pthread_create(&tid,nullptr,HandlerHttpRequest,pram);
}
}
}
http协议，如果自己写的话，本质是，我们要根据协议内容，来进行文本分析！
修改上述代码
void *HandlerHttpRequest(void *args)
{
int sock = *(int*)args;
delete (int*)args;
pthread_detach(pthread_self());
#define SIZE 1024*10
char buffer[SIZE];
memset(buffer,0,sizeof(buffer));
ssize_t s = recv(sock,buffer,sizeof(buffer),0);
if(s>0)
{
buffer[s]=0;
std::cout<<"查看http请求格式:"<<buffer; //for test
std::string http_response = "http/1.0 200 ok\n";
http_response +="Content-Type: text/plain\n";//text/plain，正文是普通的文本
http_response +="\n";//空行，用来区别报头和有效载荷
http_response += "hello sakeww!";
send(sock,http_response.c_str(),http_response.size(),0);
}
close(sock);
}
结果：当我们使用 IP+端口号 在浏览器中访问的时候，会出现我们需要的 hello sakeww!
HTTP的方法
重要：GET，POST（传输上传资源）
在网页中点击链接会直接下载文件—PUT
大部分服务器只会暴漏：GET，POST，HEAD三个方法，（为了安全，所以不暴漏其他方法）
GET
http.cc
#include "Sock.hpp"
#include<pthread.h>
//stat:获取文件相关信息
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
//C++文件操作
#include <fstream>
#define WWWROOT "./wwwroot/"
#define HOME_PAGE "index.html"
void Usage(std::string proc)
{
std::cout<< "Usage"<<proc<<"prot"<<endl;
}
void *HandlerHttpRequest(void *args)
{
int sock = *(int*)args;
delete (int*)args;
pthread_detach(pthread_self());
#define SIZE 1024*10
char buffer[SIZE];
memset(buffer,0,sizeof(buffer));
//recv是网络读取专门定制的函数 0（flags读取是否阻塞，非阻塞）
ssize_t s = recv(sock,buffer,sizeof(buffer),0);
if(s>0)
{
buffer[s]=0;
std::cout<<"查看http请求格式:"<<buffer; //for test
// std::string http_response = "http/1.0 200 ok\n";
// http_response +="Content-Type: text/plain\n";//text/plain，正文是普通的文本
// http_response +="\n";//空行，用来区别报头和有效载荷
// http_response += "hello sakeww!";
//send(sock,http_response.c_str(),http_response.size(),0);
// std::string html_file = "./wwwroot/index.html";
std::string html_file =WWWROOT;
html_file += HOME_PAGE;
struct stat st;
stat(html_file.c_str(),&st);
//返回的时候，不仅仅是返回正文网页信息，而是还要包括http的请求
std::string http_response = "http/1.0 200 OK\n";
//Content-Type正文部分的类型;charset=utf-8当前文档的字符集是采用utf-8的字符，也就是我们常说英文字符集
http_response +="Content-Type: text/html;charset=utf-8\n";//text/plain，正文是html
http_response +="Content-Length:";
http_response +=std::to_string(st.st_size);
http_response += "\n";
http_response += "\n";//添加空行
//正文：
std::ifstream in(html_file);
if(!in.is_open())
{
//open err
std::cerr << "打开失败"<<std::endl;
}
else{
std::string content;
std::string line;
while(std::getline(in,line))
{
content+=line;
}
http_response += content;
http_response +="\n";
in.close();
send(sock,http_response.c_str(),http_response.size(),0);
}
}
close(sock);
}
int main(int argc,char *argv[])
{
if(argc!=2)
{
Usage(argv[0]);
exit(1);
}
uint16_t port = atoi(argv[1]);
int listen_sock = Sock::Socket();
Sock::Bind(listen_sock,port);
Sock::Listen(listen_sock);
for(;;)
{
int sock = Sock::Accept(listen_sock);
if(sock>0)//成功
{
pthread_t tid;
int *pram = new int(sock);
pthread_create(&tid,nullptr,HandlerHttpRequest,pram);
}
}
}
Sock.hpp
#pragma once
#include<iostream>
#include<string>
#include<cstring>
#include<cstdlib>
#include<sys/socket.h>
#include<sys/types.h>
#include<netinet/in.h>
#include<arpa/inet.h>
#include<unistd.h>
using namespace std;
class Sock
{
public:
static int Socket()
{
int sock = socket(AF_INET,SOCK_STREAM,0);
if(sock < 0)
{
cerr<<"socket error"<<endl;
exit(2);
}
return sock;
}
static void Bind(int sock,uint16_t port)
{
struct sockaddr_in local;
memset(&local,0,sizeof(local));
local.sin_family = AF_INET;
local.sin_port = htons(port);
local.sin_addr.s_addr = INADDR_ANY;
if(bind(sock,(struct sockaddr*)&local,sizeof(local))<0)
{
cerr<<"bind error!"<<endl;
exit(3);
}
}
static void Listen(int sock)
{
if(listen(sock,5)<0)
{
cerr<<"listen error!"<<endl;
exit(4);
}
}
static int Accept(int sock)
{
struct sockaddr_in peer;
socklen_t len = sizeof(peer);
int fd = accept(sock,(struct sockaddr*)&peer,&len);
if(fd>0)
{
return fd;
}
else return -1;
}
static void Connect(int sock,std::string ip,uint16_t port)
{
struct sockaddr_in server;
memset(&server,0,sizeof(server));
server.sin_family = AF_INET;
server.sin_port = htons(port);
server.sin_addr.s_addr = inet_addr(ip.c_str());
if(connect(sock,(struct sockaddr*)&server,sizeof(server)) == 0)
{
cout<<"connect success!"<<endl;
}
else{
cout<<"connect failed!"<<endl;
exit(5);
}
}
};
Makefile
Http:http.cc
g++ -o $@ $^ -std=c++11 -lpthread
.PHONY:clean
clean:
rm -rf Http
wwwroot/index.html
<!-- http首页信息 -->
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>测试GET</title>
</head>
<body>
<h1>你好这是测试GET的标题</h1>
<h1>请输入账号密码</h1>
<form action="/" method="get">
姓名：<input type="text" name="name">
密码：<input type="password" name="password">
<input type="submit" value="登录">
</form>
</body>
</html>
延伸知识：
0-1023端口号是系统本身的端口号，我们是用不了的，我们开放的是别的就行
（尽量距离他们远点）
wwwroot叫做web根目录，wwwroot目录下防止的内容，就叫做资源！
wwwroot/index.html叫做网站的首页
POST
只需要将wwwroot/index.html中的get换成post即可
总结GET和POST
一、分别介绍
POST: 方法叫做：获取，是最常用的方法，默认一般获取所有的网页，都是GET方法，但是如果所有GET要提交参数，GET也是可以的，GET通过url进行参数拼接从而提交给server端
POST：方法叫做：推送，是提交参数比较常用的方法，但是如果提交参数，一般是通过正文部分提交的，但是Content-Length：表示参数的长度
二、GET和POST区别：
参数提交的位置不同
1.参数提交的位置不同，post比较私密（私密!=安全），如果安全就不可能用（fiddler）这样的抓包工具所抓，不会回显到浏览器的url输入框！get方法不私密，会将重要信息回显到url的输入框中，增加了被盗取的风险，
安全：就是要加密！
2.get是通过url传参的，而url是有大小限制的 ！这个大小和具体的浏览器有关！
post是由正文部分传参的，一般大小没有限制！
三、如何选择？
1.GET：如果提交的参数，不敏感，数量非常少，可以采用GET
2.POST：反之，，，
3.大部分情GET为主，GET不行才会选择POST
总结：
1.http协议处理，本质是文本分析
2.所谓的文本分析：
a.http协议本身的字段
b.提取参数，如果有的话
GET和POST其实是前后端交互的重要方式
HTTP的状态码
最常见的状态码, 比如 200(OK), 404(Not Found), 403(Forbidden), 302(Redirect, 重定向), 504(Bad Gateway)
应用层是人要参与的，人水平参差不齐，http的状态码，很多人根本就不清楚如何使用，又因为浏览器的种类太多，导致大家对状态码的支持并不是特别好，
类似于404的状态码，对浏览器没有任何指导意义，浏览器就是正常显示你的网页，
状态码简介
1XX：100，101表示请求正在被处理，服务器收到你的请求，但是处理你的请求需要很多时间，给你返回一个响应，（很少遇见）
2XX：200请求正常处理完毕，200的描述就是OK，我们的测试大部分都是200
3XX：重定向这里非常乱，有301，302，303，307，308不同的浏览器，不同的版本对于这种重定向的处理机制是不一样的，
4XX：403禁止访问；404内容上你访问的资源不存在，如果是“真的404”错误，就需要你自己进行处理错误，404属于客户端问题
5XX：500，503，504，服务器内部问题：来了一个请求，创建线程或者进程失败；处理请求时，做字符串分析时出现问题，程序崩溃，，，
3XX：状态码是有特殊含义的，
重定向：
当访问某一个网站的时候，可能会让我们跳转到另一个网址
当我访问某种资源的时候，提示我登录，跳转到了登录界面，当我输入完毕密码，登录的时候，会自动跳转回来（登录，美团下单）
分为：
1.永久重定向 301
用来进行：网站搬迁，域名更换
2.临时重定向 302 307
支付跳转
购买界面-》支付界面-》支付成功-》购买界面（很常用，属于一个业务环节）
模拟：
1.重定向是需要浏览器给我们提供支持的，浏览器必须识别301，302，307等等
2.server要告诉浏览器，我应该在去哪里？
Location：新的地址（http响应报头属性）
模拟301：
#include "Sock.hpp"
#include<pthread.h>
//stat:获取文件相关信息
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>
//C++文件操作
#include <fstream>
#define WWWROOT "./wwwroot/"
#define HOME_PAGE "index.html"
void Usage(std::string proc)
{
std::cout<< "Usage"<<proc<<"prot"<<endl;
}
void *HandlerHttpRequest(void *args)
{
int sock = *(int*)args;
delete (int*)args;
pthread_detach(pthread_self());
#define SIZE 1024*10
char buffer[SIZE];
memset(buffer,0,sizeof(buffer));
//recv是网络读取专门定制的函数 0（flags读取是否阻塞，非阻塞）
ssize_t s = recv(sock,buffer,sizeof(buffer),0);
if(s>0)
{
buffer[s]=0;
std::cout<<"查看http请求格式:"<<buffer; //for test
std::string response="http/1.1 301 Permanently moved\n";
response+="location: https://www.baidu.com/\n";
response+="\n";
send(sock,response.c_str(),response.size(),0);
}
close(sock);
}
int main(int argc,char *argv[])
{
if(argc!=2)
{
Usage(argv[0]);
exit(1);
}
uint16_t port = atoi(argv[1]);
int listen_sock = Sock::Socket();
Sock::Bind(listen_sock,port);
Sock::Listen(listen_sock);
for(;;)
{
int sock = Sock::Accept(listen_sock);
if(sock>0)//成功
{
pthread_t tid;
int *pram = new int(sock);
pthread_create(&tid,nullptr,HandlerHttpRequest,pram);
}
}
}
在浏览器输入
ip+端口号
会直接进入百度首页
模拟302：
代码方面：
直接修改301-》302即可
在浏览器输入
ip+端口号+回车（注意：在没有回车的时候，ip+端口号前面图标显示内容1）
会直接进入百度首页
重新输入ip+端口号（前面会显示 百度的图标）
HTTP常见Header
Content-Type: 数据类型(text/html等)
Content-Length: Body的长度
（当你的正文不存在的时候，你的Content_Length就可以不存在）
Host: 客户端告知服务器, 所请求的资源是在哪个主机的哪个端口上;
User-Agent: 声明用户的操作系统和浏览器版本信息;
referer: 当前页面是从哪个页面跳转过来的;
location: 搭配3xx状态码使用, 告诉客户端接下来要去哪里访问;
Cookie: 用于在客户端存储少量信息. 通常用于实现会话(session)的功能;
我们之前所有的实验，全部都是请求，响应，断开连接
服务器上有很多资源
一个大型的网页资源，是由非常多个资源组成的，每个资源都要发起http请求（短链接）！即需要发送很多请求
Connection：keep-alive
一般而言，一个大网页是由多个元素组成的！
http/1.0采用的网络请求的方案是短链接
request->response->close~~>返回一个资源
访问一个由多个元素构成的网页的时候，
http/1.0，需要多次进行http请求
http协议是基于tcp协议的，tcp要通信
建立链接->传送数据->断开链接~~>每次http request都要执行，整体比较耗时
http/1.1之后都是长链接，需要设置Connection：keep-alive（保持活着）
通过频繁建立tcp链接，来达到提高效率的目的
cookie 和 session
cookie
http协议本身是一种无状态的协议！
在网站中，各种页面跳转的时候，本质就是进行各种http请求，网站照样认识我！
并不是http协议本身要解决的问题
http可以提供一些技术支持，来保证网站具有“会话保持”的功能（cookie）（会话管理）
http主要帮我们解决网络资源获取的问题
cookie
1.浏览器：cookie其实是一个文件，该文件保存的是我们的用户的私密信息
2.http:一旦该网站对应有cookie，在发起任何请求的时候，都会自动在request携带该cookie信息
补充：
这个文件在浏览器中
我们在客户端的浏览器里面，进行登录请求
服务器会回复我们登陆成功的信息
此时浏览器会自动保存登录相关信息到cookie这个文件
后续的请求浏览器会，将每一个请求都会请求报头属性中，会自动携带对应的cookie
Set_cookie:服务器向浏览器设置一个cookie
存在形式：
1.文件版
2.内存版
如果别人盗取我们的cookie文件，别人可以：
1.可以以我的身份进行认证访问特定的资源！
2.如果保存的是我们的用户名和密码，
单纯使用cookie是具有一定的安全隐患的
session
核心思路：将用户的私密信息，保存在服务器上
客户端向服务端发送登录信息，会包含（id+密码）
服务端在其磁盘形成session文件，内包含了id+密码
服务端向客户端返回一个session，
客户端的cookie保存了session
客户端以后的每次向服务端申请服务都会提供session
服务端对齐进行检测才可以
session文件的形成包含很多：一个人的手机号，地域信息，指纹，脸部，最后才是id+密码
cookie和session的本质：提高用户访问网站或平台的体验！
https
预备知识：
https = http+ TLS/SSL(http数据的加密解密层)
加密方式：
1.对称加密，密钥（只有一个）X
用X加密（data^X=result）
也要用X解密(result^X=data)
2.非对称加密,有一对密钥：公钥和私钥
可以用公钥加密，但是只能用私钥解密
或者用私钥加密，只能用公钥解密
常见算法：RSA
一般而言，公钥是全世界公开的，私钥是必须自己进行私有保存的！
如何防止文本中的内容被篡改？以及识别到是否被篡改？
https是如何通信的
客户端向服务端发送登录信息
服务端向客户端发送一个公钥和其他数据
客户端通过公钥对自己的数据进行加密，然后发送给服务端
服务端通过私钥对自己的数据进行解密，然后才能获取数据
（上述只能保证客户端到服务端的数据安全）
（这是一个非对称密钥）
推论：
既然一对非对称密钥，能保证数据的单向安全
那么两对非对称密钥，就能保证数据的双向安全？
但是，事实并非如此！
1.依旧有被非法窃取的风险！
2.非对称加密算法，特别费时间！（因为这个，所以这个方法不行！）
实际：非对称+对称方案
什么叫做安全？
不是让别人拿不到，就叫做安全
别人拿到了，也没法处理！
解密的成本大于加密成本
成本（钱，国家安全）
“实际”的问题：
CA机构：只要一个服务商，经过权威机构认证，该机构就是合法的
属性：
1.权威
2.有自己的公钥A和私钥A’
CA的公钥是全世界都知道的，但是CA的私钥只有CA自己知道，换言之世界上，只有CA机构能重新形成对应的数字签名！
1.CA公钥一般是内置的，所以用户知道（主流）
2.访问网址的时候，浏览器可能会提示用户进行安装！
传输层
负责数据能够从发送端传输接收端.
端口号范围划分：
0 - 1023: 知名端口号, HTTP, FTP, SSH等这些广为使用的应用层协议, 他们的端口号都是固定的
1024 - 65535: 操作系统动态分配的端口号. 客户端程序的端口号, 就是由操作系统从这个范围分配的
ssh服务器, 使用22端口
ftp服务器, 使用21端口
telnet服务器, 使用23端口
http服务器, 使用80端口
https服务器, 使用443
执行下面的命令, 可以看到知名端口号:cat /etc/services
问题：
1.一个进程是否可以bind多个端口号?
是，我们当初用自己的ip+端口号 访问了baidu.com
ftp在有些情况下，一个网络服务绑定了几个端口号
2.一个端口号是否可以被多个进程bind?
否，当我们在绑定端口号的时候，往往会因为端口号被占，从而使我们绑定不了这个端口号
netstat
netstat是一个用来查看网络状态的重要工具
语法： netstat [选项]
功能：查看网络状态
常用选项：
n 拒绝显示别名，能显示数字的全部转化成数字
l 仅列出有在 Listen (监听) 的服務状态
p 显示建立相关链接的程序名
t (tcp)仅显示tcp相关选项
u (udp)仅显示udp相关选项
a (all)显示所有选项，默认不显示LISTEN相关
pidof
在查看服务器的进程id时非常方便
语法： pidof [进程名]
功能：通过进程名, 查看进程id
UDP协议
UDP协议端格式
16位UDP长度, 表示整个数据报(UDP首部+UDP数据)的最大长度;
如果校验和出错, 就会整体直接丢弃;
UDP
1.如何做到封装和解包
封装：添加定长报头
解包：报头和有效载荷进行分离
2.如何做到向上交付（分用问题）
需要解决：
a.报头和有效载荷分离
b.根据目的端口号，交付有效载荷给上层应用
Linux kernel 是用c语言写的，请问如何看待udp报文（报头）？
struct udp_hdr{
uint32_t src_port;
uint32_t dst_port;
uint32_t total;
uint32_t check;
}
UDP的特点
UDP传输的过程类似于寄信.
无连接: 知道对端的IP和端口号就直接进行传输, 不需要建立连接;
不可靠: 没有确认机制, 没有重传机制; 如果因为网络故障该段无法发到对方, UDP协议层也不会给应用层返回任何错误信息;
面向数据报: 不能够灵活的控制读写数据的次数和数量;（只能读取完整的UDP数据，要么不读，要么读取至少一份UDP数据）
面向数据报
应用层交给UDP多长的报文, UDP原样发送, 既不会拆分, 也不会合并;
用UDP传输100个字节的数据:
如果发送端调用一次sendto, 发送100个字节, 那么接收端也必须调用对应的一次recvfrom, 接收100个字节; 而不能循环调用10次recvfrom, 每次接收10个字节;
UDP的缓冲区
UDP没有真正意义上的 发送缓冲区. 调用sendto会直接交给内核, 由内核将数据传给网络层协议进行后续的传输动作;
UDP具有接收缓冲区. 但是这个接收缓冲区不能保证收到的UDP报的顺序和发送UDP报的顺序一致; 如果缓冲区满了, 再到达的UDP数据就会被丢弃;
UDP的socket既能读, 也能写, 这个概念叫做 全双工
udp全双工：
1.两个人吵架（全双工）recvfrom，sendto可以被同时调用
2.两个人聊天，你一句我一句（双方都叫做：半双工）
3.老师上课，老师单方面说话（半双工）
UDP使用注意事项
我们注意到, UDP协议首部中有一个16位的最大长度. 也就是说一个UDP能传输的数据最大长度是64K(包含UDP首部).
然而64K在当今的互联网环境下, 是一个非常小的数字.
如果我们需要传输的数据超过64K, 就需要在应用层手动的分包, 多次发送, 并在接收端手动拼装;
基于UDP的应用层协议
NFS: 网络文件系统
TFTP: 简单文件传输协议
DHCP: 动态主机配置协议
BOOTP: 启动协议(用于无盘设备启动)
DNS: 域名解析协议
TCP协议
TCP全称为 “传输控制协议(Transmission Control Protocol”). 人如其名, 要对数据的传输进行一个详细的控制;
TCP协议段格式
TCP
1.如何做到封装和解包？
根据4位首部长度，判断报头大小，从而封装和解包
2.如何做到向上交付（分用问题）
根据目的端口号来查找上层应用程序
序号问题：
TCP叫做保证可靠性：
必须理解TCP中可靠性，最核心的机制：基于序号的确认应带机制！
通过应答，来保证上一条信息被对方百分之百收到了！
TCP并不是百分之百可靠的！（最新的消息不能确认）
TCP的可靠性–是对历史信息的可靠性
可靠性：除了保证被对方收到，也要保证按序达到！
TCP包含32位的序号作用：保证按序到达
如何确认：tcp报头中函给一个确认序号，是对历史确认报文的序号+1
收到确认应答tcp报文之后，可以通过确认序号，来辨别是对哪一个报文的确认
例如：确认序号：15
15之前的所有报文我已经全部收到了，下次发送请从15号报文开始发送！
无论是数据，还是应答，本质都是一整个TCP报文
可以不携带数据，但是一定要具有一个完整的tcp报头
一个报文既有序号，又有报文序号。
为何是两个独立的字段呢？
tcp是一个全双工的通信协议！！！（吵架）
tcp协议，是自带发送和接受缓冲区的！TCP malloc 2段内存空间！
write/send：与其叫做发送接口，不如理解为拷贝函数，应用层进行send，并不是把数据发到网络上，而是把数据拷贝进TCP的发送缓冲区
read/recv：同理
为什么？
1.提高应用层效率
2.只有OS TCP协议才可以知道网络，乃至对方状态明细，即：TCP协议知道如何发？什么时候发？发多少？出错了，怎么办？等细节问题
因为缓冲区的存在，所以可以做到应用层和TCP进行解耦！
当客户端向服务端发送大量信息的时候，
对方来不及接受，对方只能丢弃，
这是问题吗？
不算，即便丢弃了，tcp有一个丢包重传，
但是这样会浪费很多资源，
解决：流量控制—
可以在应答报文：在报头里面填上：我自己的接受缓冲区中剩余空间的大小（16位窗口大小）
6个标记位：在四个首部长度 之后
tcp协议是面向链接的
tcp socket，要通信的时候，需要先connect！
~~>通信前，要先建立链接（保证可靠性）
如何建立？三次握手->三次数据交换->交换三次报文
为什么要有？
1.server可能在任何一个时间，都有可能有成千上万个报文在向serve发送数据
2.server首先面临的是，面对大量的TCP报文，如何区分各个报文的类别！
3.通过TCP的标志位来进行区分，不同种类的TCP报文
ACK:表明这个报文是一个 “确认”报文
几乎，在所有的TCP通信的过程中，ACK都会被设置
SYN：同步标记位，表明这个报文是一个 “链接建立请求”
什么是连接？
server存在大量的连接
server该如何管理这些连接？先描述，在组织
建立连接的本质：三次握手成功，一定要在双方的操作系统内，为维护该连接创建对应的数据结构
双方维护连接是有成本的（时间+空间）
为什么是三次握手？
第一次和第二次都有应答，所以第一二次是否成功没关系，所以不用担心前两次
第三次没有应答，我们需要担心这个
即：三次握手是：以较大概率建立链接的过程
为什么是三次握手，而不是其他次数的握手？
对方好着没？网络好着没？
1.确认双方主机是否健康
2.验证全双工，三次握手，我们能看到双方都有收发的最小的次数！（验证双方都有收发的能力）
发送大量的SYN：叫做SYN洪水
一般而言，双方握手，是有一个短暂的时间差的
RST：重置异常链接，是双方连接出现异常，都可以进行reset，来进行连接重置
断开连接的本质：双方达到链接都应该断开的共识就是一个通知对方的机制
是协商断开连接的最小次数
PSH：push
告知对方，尽快将接收缓冲区尽快向上交付
URG：紧急指针标记位
目前因为TCP有按序到达，每一个报文，什么时候被上层读取到基本是确定的！
如果想让一些数据尽快的被上层读到，URG表明该报文中携带了紧急数据，需要被优先处理~~>紧急数据在哪里？十六位紧急指针
tcp的紧急指针只能传输一个字节
FIN：断开链接请求（四次挥手）
超时重传机制
主机A发送数据给B之后, 可能因为网络拥堵等原因, 数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答, 就会进行重发
但是, 主机A未收到B发来的确认应答, 也可能是因为ACK丢失了
因此主机B会收到很多重复数据. 那么TCP协议需要能够识别出那些包是重复的包, 并且把重复的丢弃掉.
这时候我们可以利用前面提到的序列号, 就可以很容易做到去重的效果.
那么, 如果超时的时间如何确定?
最理想的情况下, 找到一个最小的时间, 保证 “确认应答一定能在这个时间内返回”.
但是这个时间的长短, 随着网络环境的不同, 是有差异的.
如果超时时间设的太长, 会影响整体的重传效率;
如果超时时间设的太短, 有可能会频繁发送重复的包;
TCP为了保证无论在任何环境下都能比较高性能的通信, 因此会动态计算这个最大超时时间.
Linux中(BSD Unix和Windows也是如此), 超时以500ms为一个单位进行控制, 每次判定超时重发的超时时间都是500ms的整数倍.
如果重发一次之后, 仍然得不到应答, 等待 2500ms 后再进行重传.
如果仍然得不到应答, 等待 4500ms 进行重传. 依次类推, 以指数形式递增.
累计到一定的重传次数, TCP认为网络或者对端主机出现异常, 强制关闭连接
时间间隔，网络是变化的，网络通信的效率也是变化的，发送数据得到ACK时间也是浮动的，超时重传的时间一定是浮动的
连接管理机制
服务端状态转化:
[CLOSED -> LISTEN] 服务器端调用listen后进入LISTEN状态, 等待客户端连接;
[LISTEN -> SYN_RCVD] 一旦监听到连接请求(同步报文段), 就将该连接放入内核等待队列中, 并向客户端发送SYN确认报文
[SYN_RCVD -> ESTABLISHED] 服务端一旦收到客户端的确认报文, 就进入ESTABLISHED状态, 可以进行读写数据了.
[ESTABLISHED -> CLOSE_WAIT] 当客户端主动关闭连接(调用close), 服务器会收到结束报文段, 服务器返回确认报文段并进入CLOSE_WAIT;
[CLOSE_WAIT -> LAST_ACK] 进入CLOSE_WAIT后说明服务器准备关闭连接(需要处理完之前的数据); 当服务器真正调用close关闭连接时, 会向客户端发送FIN, 此时服务器进入LAST_ACK状态, 等待最后一个ACK到来(这个ACK是客户端确认收到了FIN)
[LAST_ACK -> CLOSED] 服务器收到了对FIN的ACK, 彻底关闭连接.
客户端状态转化:
[CLOSED -> SYN_SENT] 客户端调用connect, 发送同步报文段;
[SYN_SENT -> ESTABLISHED] connect调用成功, 则进入ESTABLISHED状态, 开始读写数据;
[ESTABLISHED -> FIN_WAIT_1] 客户端主动调用close时, 向服务器发送结束报文段, 同时进入FIN_WAIT_1;
[FIN_WAIT_1 -> FIN_WAIT_2] 客户端收到服务器对结束报文段的确认, 则进入FIN_WAIT_2, 开始等待服务器的结束报文段;
[FIN_WAIT_2 -> TIME_WAIT] 客户端收到服务器发来的结束报文段, 进入TIME_WAIT, 并发出LAST_ACK;
[TIME_WAIT -> CLOSED] 客户端要等待一个2MSL(Max Segment Life, 报文最大生存时间)的时间, 才会进入CLOSED状态
下图是TCP状态转换的一个汇总
较粗的虚线表示服务端的状态变化情况;
较粗的实线表示客户端的状态变化情况;
CLOSED是一个假想的起始点, 不是真实状态;
理解TIME_WAIT状态
现在做一个测试,首先启动server,然后启动client,然后用Ctrl-C使server终止,这时马上再运行server, 结果是
这是因为,虽然server的应用程序终止了,但TCP协议层的连接并没有完全断开,因此不能再次监 听同样的server端口.我们用netstat命令查看一下:
TCP协议规定,主动关闭连接的一方要处于TIME_ WAIT状态,等待两个MSL(maximum segment lifetime)的时间后才能回到CLOSED状态.
我们使用Ctrl-C终止了server, 所以server是主动关闭连接的一方, 在TIME_WAIT期间仍然不能再次监听同样的server端口;
MSL在RFC1122中规定为两分钟,但是各操作系统的实现不同, 在Centos7上默认配置的值是60s;
可以通过 cat /proc/sys/net/ipv4/tcp_fin_timeout 查看msl的值;
为什么是TIME_WAIT的时间是2MSL?
MSL是TCP报文的最大生存时间, 因此TIME_WAIT持续存在2MSL的话
就能保证在两个传输方向上的尚未被接收或迟到的报文段都已经消失(否则服务器立刻重启, 可能会收到来自上一个进程的迟到的数据, 但是这种数据很可能是错误的);
同时也是在理论上保证最后一个报文可靠到达(假设最后一个ACK丢失, 那么服务器会再重发一个FIN. 这时虽然客户端的进程不在了, 但是TCP连接还在, 仍然可以重LAST_ACK);
即：
1.尽量保证历史发送的网络数据在网络中消散
2.尽量的保证，最后一个ACK被对方收到
TIME_WAIT状态引起的bind失败的方法
在server的TCP连接没有完全断开之前不允许重新监听, 某些情况下可能是不合理的
服务器需要处理非常大量的客户端的连接(每个连接的生存时间可能很短, 但是每秒都有很大数量的客户端来请求).
这个时候如果由服务器端主动关闭连接(比如某些客户端不活跃, 就需要被服务器端主动清理掉), 就会产生大量TIME_WAIT连接.
由于我们的请求量很大, 就可能导致TIME_WAIT的连接数很多, 每个连接都会占用一个通信五元组(源ip,源端口, 目的ip, 目的端口, 协议). 其中服务器的ip和端口和协议是固定的. 如果新来的客户端连接的ip和端口号和TIME_WAIT占用的链接重复了, 就会出现问题
使用setsockopt()设置socket描述符的 选项SO_REUSEADDR为1, 表示允许创建端口号相同但IP地址不同的多个socket描述符
理解 CLOSE_WAIT 状态
对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成. 这是一个 BUG. 只需要加上对应的 close 即可解决问题
滑动窗口
确认应答策略, 对每一个发送的数据段, 都要给一个ACK确认应答. 收到ACK后再发送下一个数据段.这样做有一个比较大的缺点, 就是性能较差. 尤其是数据往返的时间较长的时候.
既然这样一发一收的方式性能较低, 那么我们一次发送多条数据, 就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了).
窗口大小指的是无需等待确认应答而可以继续发送数据的最大值. 上图的窗口大小就是4000个字节(四个段).
发送前四个段的时候, 不需要等待任何ACK, 直接发送;
收到第一个ACK后, 滑动窗口向后移动, 继续发送第五个段的数据; 依次类推;
操作系统内核为了维护这个滑动窗口, 需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答; 只有确认应答过的数据, 才能从缓冲区删掉;
窗口越大, 则网络的吞吐率就越高;
滑动窗口情况一：数据包已经抵达, ACK被丢了
部分ACK丢了并不要紧, 因为可以通过后续的ACK进行确认
滑动窗口情况二: 数据包就直接丢了
当某一段报文段丢失之后, 发送端会一直收到 1001 这样的ACK, 就像是在提醒发送端 "我想要的是 1001"一样;
如果发送端主机连续三次收到了同样一个 “1001” 这样的应答, 就会将对应的数据 1001 - 2000 重新发送;
这个时候接收端收到了 1001 之后, 再次返回的ACK就是7001了(因为2001 - 7000)接收端其实之前就已经收到了, 被放到了接收端操作系统内核的接收缓冲区中;
这种机制被称为 “高速重发控制”(也叫 “快重传”)
快重传 vs 超时重传
（超时重传是TCP协议保证数据可靠性的另一个重要机制，其原理是在发送某一个数据以后就开启一个计时器，在一定时间内如果没有得到发送的数据报的ACK报文，那么就重新发送数据，直到发送成功为止。）
快重传有要求，必须收到三个同样的确认应答时则进行重传，保证能重传的情况下，提高效率的
流量控制
接收端处理数据的速度是有限的. 如果发送端发的太快, 导致接收端的缓冲区被打满, 这个时候如果发送端继续发送,就会造成丢包, 继而引起丢包重传等等一系列连锁反应.
因此TCP支持根据接收端的处理能力, 来决定发送端的发送速度. 这个机制就叫做流量控制(Flow Control)
1.什么时候主机A，能知道主机B的接受能力？
取决于对方什么时候给我发送的第一个报文，
第一个报文在三次握手的时候就已经交互了，握手期间，协商窗口大小，根据对方的窗口大小，来设置自己的滑动窗口的初始值
2.如果我的接收缓冲区窗口大小为零，该如何？
接收端如何把窗口大小告诉发送端呢? 回忆我们的TCP首部中, 有一个16位窗口字段, 就是存放了窗口大小信息;
那么问题来了, 16位数字最大表示65535, 那么TCP窗口最大就是65535字节么?
实际上, TCP首部40字节选项中还包含了一个窗口扩大因子M, 实际窗口大小是 窗口字段的值左移 M 位
拥塞控制
虽然TCP有了滑动窗口这个大杀器, 能够高效可靠的发送大量的数据. 但是如果在刚开始阶段就发送大量的数据, 仍然可能引发问题.
因为网络上有很多的计算机, 可能当前的网络状态就已经比较拥堵. 在不清楚当前网络状态下, 贸然发送大量的数据,是很有可能引起雪上加霜的.
TCP引入 慢启动 机制, 先发少量的数据, 探探路, 摸清当前的网络拥堵状态, 再决定按照多大的速度传输数据;
大面积的网路丢包，取决于tcp的实现
为什么是慢启动？
因为指数级别的增长，前期慢，后期会快的，（试探）
网络传输中，网络是有一个载荷的，
这个载荷负责的是很多人之间的传输，这个载荷是不停的变化的（人数，环境，，，，）
所以这个载荷需要被探测出来，
为什么探测？tcp想把数据尽快发送给对方
延迟应答
当接收到对方的报文的时候，
如果立即ACK，那么返回的空间大小是剩余的大小
如果等一会再发送ACK，那么返回的空间大小会比较大
窗口越大, 网络吞吐量就越大, 传输效率就越高. 我们的目标是在保证网络不拥塞的情况下尽量提高传输效率
那么所有的包都可以延迟应答么? 肯定也不是;
数量限制: 每隔N个包就应答一次;
时间限制: 超过最大延迟时间就应答一次;
具体的数量和超时时间, 依操作系统不同也有差异; 一般N取2, 超时时间取200ms
捎带应带
再回复ACK的时候，还可以捎带一些数据返回给对方
面向字节流
创建一个TCP的socket, 同时在内核中创建一个 发送缓冲区 和一个 接收缓冲区;
调用write时, 数据会先写入发送缓冲区中;
如果发送的字节数太长, 会被拆分成多个TCP的数据包发出;
如果发送的字节数太短, 就会先在缓冲区里等待, 等到缓冲区长度差不多了, 或者其他合适的时机发送出去;
接收数据的时候, 数据也是从网卡驱动程序到达内核的接收缓冲区;
然后应用程序可以调用read从接收缓冲区拿数据;
另一方面, TCP的一个连接, 既有发送缓冲区, 也有接收缓冲区, 那么对于这一个连接, 既可以读数据, 也可以写数据. 这个概念叫做 全双工
由于缓冲区的存在, TCP程序的读和写不需要一一匹配, 例如:
写100个字节数据时, 可以调用一次write写100个字节, 也可以调用100次write, 每次写一个字节;
读100个字节数据时, 也完全不需要考虑写的时候是怎么写的, 既可以一次read 100个字节, 也可以一次read一个字节, 重复100次
udp必须要读和写需要匹配，–》用户数据报
粘包问题
首先要明确, 粘包问题中的 “包” , 是指的应用层的数据包.
在TCP的协议头中, 没有如同UDP一样的 “报文长度” 这样的字段, 但是有一个序号这样的字段.
站在传输层的角度, TCP是一个一个报文过来的. 按照序号排好序放在缓冲区中.
站在应用层的角度, 看到的只是一串连续的字节数据.
那么应用程序看到了这么一连串的字节数据, 就不知道从哪个部分开始到哪个部分, 是一个完整的应用层数据包.
那么如何避免粘包问题呢? 归根结底就是一句话, 明确两个包之间的边界.
对于定长的包, 保证每次都按固定大小读取即可; 例如上面的Request结构, 是固定大小的, 那么就从缓冲区从头开始按sizeof(Request)依次读取即可;
对于变长的包, 可以在包头的位置, 约定一个包总长度的字段, 从而就知道了包的结束位置;
对于变长的包, 还可以在包和包之间使用明确的分隔符(应用层协议, 是程序猿自己来定的, 只要保证分隔符不和正文冲突即可);
思考: 对于UDP协议来说, 是否也存在 “粘包问题” 呢?
对于UDP, 如果还没有上层交付数据, UDP的报文长度仍然在. 同时, UDP是一个一个把数据交付给应用层. 就有很明确的数据边界.
站在应用层的站在应用层的角度, 使用UDP的时候, 要么收到完整的UDP报文, 要么不收. 不会出现"半个"的情况
TCP异常情况
进程终止: 进程终止会释放文件描述符, 仍然可以发送FIN. 和正常关闭没有什么区别.
机器重启: 和进程终止的情况相同.
机器掉电/网线断开: 接收端认为连接还在, 一旦接收端有写入操作, 接收端发现连接已经不在了, 就会进行reset. 即使没有写入操作, TCP自己也内置了一个保活定时器, 会定期询问对方是否还在. 如果对方不在, 也会把连接释放.
另外, 应用层的某些协议, 也有一些这样的检测机制. 例如HTTP长连接中, 也会定期检测对方的状态. 例如QQ, 在QQ断线之后, 也会定期尝试重新连接
TCP小结
为什么TCP这么复杂? 因为要保证可靠性, 同时又尽可能的提高性能.
可靠性:
校验和
序列号(按序到达)
确认应答
超时重发
连接管理
流量控制
拥塞控制
提高性能:
滑动窗口
快速重传
延迟应答
捎带应答
其他:
定时器(超时重传定时器, 保活定时器, TIME_WAIT定时器等)
基于TCP应用层协议
HTTP
HTTPS
SSH
Telnet
FTP
SMTP
当然, 也包括你自己写TCP程序时自定义的应用层协议;
TCP/UDP对比
我们说了TCP是可靠连接, 那么是不是TCP一定就优于UDP呢? TCP和UDP之间的优点和缺点, 不能简单, 绝对的进行比较
TCP用于可靠传输的情况, 应用于文件传输, 重要状态更新等场景;
UDP用于对高速传输和实时性要求较高的通信领域, 例如, 早期的QQ, 视频传输等. 另外UDP可以用于广播;
归根结底, TCP和UDP都是程序员的工具, 什么时机用, 具体怎么用, 还是要根据具体的需求场景去判定。
用UDP实现可靠传输(经典面试题)
参考TCP的可靠性机制, 在应用层实现类似的逻辑;
例如:
引入序列号, 保证数据顺序
引入确认应答, 确保对端收到了数据;
引入超时重传, 如果隔一段时间没有应答, 就重发数据;
…
TCP 相关实验
理解 listen 的第二个参数
代码描述与修改：
在Sock.hpp中
将listen、中的第二个参数设为1
在http.cc中
将需要运行函数设为死循环
运行方法：
./Http
用多台服务器连接这个端口（3个以上）
我们netstat -npt 查看连接个数
现象：
只有两个ESTABLISHED
一个SYN_RECV
现象解释：
客户端状态正常, 但是服务器端出现了 SYN_RECV 状态, 而不是 ESTABLISHED 状态
这是因为, Linux内核协议栈为一个tcp连接管理使用两个队列:
1.半链接队列（用来保存处于SYN_SENT和SYN_RECV状态的请求）
2.全链接队列（accpetd队列）（用来保存处于established状态，但是应用层没有调用accept取走的请求）
而全连接队列的长度会受到 listen 第二个参数的影响.
全连接队列满了的时候, 就无法继续让当前连接的状态进入 established 状态了.
这个队列的长度通过上述实验可知, 是 listen 的第二个参数 + 1
为什么要维护队列，为什么这个队列不能太长，为什么这个队列不能没有！（全链接）
6840
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
