前言
Http我們都已經耳熟能詳了，而關于Http學習的文章網上有很多，各個知識點的講解也可說是深入淺出，然而，學習過后，我們對Http還是一知半解，問題出在了哪？
Http是一個客戶機與服務器之間的通信的協議，真的想學習Http，就必須把客戶機和服務器也學了，也就是說，必須立體的學習，不然我們永遠都是一知半解，
現在，我們手工搭建一個服務器，立體的學習下Http，將我們以為的知識點連成線，
定義
學習前，簡單的了解下定義：
Http是超文本傳輸協議，用于保證客戶機與服務器之間的通信，在客戶機和服務器之間進行請求-回應時，兩種最常被用到的方法是：GET 和 POST，
-
GET - 從指定的資源請求資料，
-
POST - 向指定的資源提交要被處理的資料(向指定資源“追加/添加”資料，)
搭建Http服務器
首先我們通過HttpListener來搭建一個簡易的Http服務器，代碼如下：
class Program
{
static HttpListener httpListener;
static volatile bool isRun = true;
static void Main(string[] args)
{
Listener(5180);
}
public static void Listener(int port)
{
//創建HTTP監聽
httpListener = new HttpListener();
//監聽的路徑
httpListener.Prefixes.Add($"http://localhost:{port}/");
httpListener.Prefixes.Add($"http://127.0.0.1:{port}/");
//設定匿名訪問
httpListener.AuthenticationSchemes = AuthenticationSchemes.Anonymous;
//開始監聽
httpListener.Start();
while (isRun)
{
//等待傳入的請求接受到請求時回傳，它將阻塞執行緒，直到請求到達
var context = httpListener.GetContext();
//取得請求的物件
HttpListenerRequest request = context.Request;
Console.WriteLine($"請求模式：{request.HttpMethod}");
var reader = new StreamReader(request.InputStream, Encoding.UTF8);
var msgSource = reader.ReadToEnd();//讀取傳過來的資訊+
Console.WriteLine($"msgSource：{msgSource}");
var msg = Uri.UnescapeDataString(msgSource);
Console.WriteLine($"請求msg：{msg}");
string responseString = "回傳值";
// 取得回應物件
HttpListenerResponse response = context.Response;
?
// 設定回應頭部內容，長度，編碼
response.ContentEncoding = Encoding.UTF8;
response.ContentType = "text/plain; charset=utf-8";
?
response.Headers.Add("Access-Control-Allow-Origin", "*");
response.Headers.Add("Cache-Control", "no-cache");
?
byte[] buff = Encoding.UTF8.GetBytes(responseString);
?
// 輸出回應內容
System.IO.Stream output = response.OutputStream;
output.Write(buff, 0, buff.Length);
// 必須關閉輸出流
output.Close();
}
}
}
服務器搭建已經搭建完成了，現在，我們通過代碼從新學習一下Http定義，
代碼學習
首先我們看到，httpListener.GetContext()阻塞了執行緒；只有請求到達時，執行緒才會繼續運行，請求到達時，我們將會得到一個HttpListenerRequest的請求物件，
HttpListenerRequest物件包含了請求的地址欄引數QueryString、Cookies、請求頭Header等等資訊，
Get請求
Get請求很簡單，Get請求的資料就寫在地址欄，所以我們直接可以使用HttpListenerRequest物件的QueryString來讀取到，如下：
HttpListenerRequest request = context.Request; //取得請求的物件
Console.WriteLine($"請求模式：{request.HttpMethod}");
var abc = request.QueryString["abc"];
Console.WriteLine($"Get請求abc的值：{abc}");
運行Host專案，測驗如下圖所示：
Post請求
學習了上面的代碼，我想一定有人對下面這句話感到疑惑，
var reader = new StreamReader(request.InputStream, Encoding.UTF8);
為什么請求已經到了，還要去讀請求中的InputStream屬性呢？
我們重新看下Post的定義：向指定的資源提交要被處理的資料(向指定資源“追加/添加”資料，)，
定義太不好理解，我們翻譯一下；Post的請求是先發起，一個TCP連接，然后再將資料，寫入請求的InputStream屬性中，
現在我們撰寫一個Http的Post請求，加深理解，
public static void Post(string url, string param, Action<string> callback)
{
new Task(() =>
{
try
{
//轉換輸入引數的編碼型別，獲取bytep[]陣列
byte[] byteArray = Encoding.UTF8.GetBytes(param);
//初始化新的webRequst
//1． 創建httpWebRequest物件
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create(new Uri(url));
//2． 初始化HttpWebRequest物件
webRequest.Method = "POST";
webRequest.ContentType = "application/x-www-form-urlencoded";
webRequest.ContentLength = byteArray.Length;
//3． 附加要POST給服務器的資料到HttpWebRequest物件(附加POST資料的程序比較特殊，它并沒有提供一個屬性給用戶存取，需要寫入HttpWebRequest物件提供的一個stream里面，)
Stream newStream = webRequest.GetRequestStream();//創建一個Stream,賦值是寫入HttpWebRequest物件提供的一個stream里面
newStream.Write(byteArray, 0, byteArray.Length);
newStream.Close();
//4． 讀取服務器的回傳資訊
using (HttpWebResponse response = (HttpWebResponse)webRequest.GetResponse())
{
using (StreamReader stream = new StreamReader(response.GetResponseStream(), Encoding.UTF8))
{
string ret = stream.ReadToEnd();
callback(ret);
}
}
}
catch (Exception ex)
{
callback("例外：" + ex.Message);
}
}).Start();
}
可以看到，請求時，就是從指定IP地址中創建一個WebRequest物件（通過WebRequest.Create創建），然后再獲取物件的請求流—GetRequestStream()，即服務端的InputStream，再向其流里寫人資料，
現在我們撰寫一個Winform專案，測驗一下Post請求，結果如下：
擴展1：Http本質上是TCP，也就是說Get請求，不去讀取InputStream里的值，是被框架處理的結果呈現，如果框架處理了Get請求的InputStream，那么Get請求就也可以像Post那樣，獲取請求中的InputStream，然后向流里寫入資料，這就是為什么有的框架Get請求也可以發送Json物件的原因，
擴展2：Post請求需要讀取InputStream，也就是說，每次的Post都需要實體化一個Tcp物件去處理流，而Get請求不去讀InputStream，就不用實體化Tcp了，也就是說Get請求的記憶體消耗更少，同理，上文提到的Get請求發送Json物件，就等于把Get請求變成了Post請求，即，大量消耗了記憶體，所以，如果網站需要性能好一點的話，就盡量不考慮使用這樣的框架，
擴展3：在Post請求中，我們把寫入InputStream的資料稱為Content，而在HttpListenerRequest類的截圖中，我們可以看到這三個屬性ContentLength64，ContentType，ContentEncoding，他們代表著，Content的長度、型別、編碼，也就是說，如果我們手寫Post請求，這三個值一定要服務器決議時配置的值對上，當然，他們也都是有默認值的，通常服務器都會支持多種ContentType型別，如application/x-www-form-urlencoded或application/json，具體各種型別的資料格式，大家可以自行了解，
擴展4：MVC和WebApi都是在Http決議后執行的，也就是說，服務器先決議了Http，然后才根據請求的Url決議跳轉到指定Controler和Action，然后再實體化Controler和Action時，在把相應的引數傳遞過去，
請求亂碼
在客戶端Http發起請求時，英文字母，數字會原樣發送，而中文和其他字符，則直接把字串用BASE64加密，如：%E5%95%8A%20%E4%B8%8D，這種行為，我們稱之為字串轉義，
同理，在服務器端，我們需要將請求的字串決議回來，如Uri.UnescapeDataString(msgSource)，
那為什么會有亂碼？
我們會發現，亂碼出現的地方都是中文和特殊字符，那么結合上文所述，我們就知道亂碼出現的原因了，
兩種情況，一種是框架沒有做決議，或者決議失敗，直接把客戶端的轉義后的請求發給了你；另一種是客戶端和服務器的決議型別沒對上，進行了錯誤的決議，
不過，通常情況下，服務器會替我們做好解碼的作業，
跨域
上文中，我們看到在輸出回傳資料的時候，我們為HttpListenerResponse物件的Headers屬性增加了個鍵值對，如下：
response.Headers.Add("Access-Control-Allow-Origin", "*");
沒錯，這個是跨域的配置，我們在Response輸出時，進行了Access-Control-Allow-Origin配置，這樣，瀏覽器在接受到我們的回傳訊息時，就不會阻止它們顯示了，
結語
立體的學習了Http后，我們才能更好，更快的學習Http協議，一些以前我們很難理解的解釋，也可以慢慢想通了，比如Connection: keep-alive，我們現在就能更好的理解了，它就是Http請求后，不去釋放Tcp物件，這樣，它下一次傳輸資料就不用新建記憶體了，
----------------------------------------------------------------------------------------------------
到此HTTP的立體學習已經介紹完了，代碼已經傳到Github上了，歡迎大家下載，
代碼已經傳到Github上了，歡迎大家下載，
Github地址：https://github.com/kiba518/HttpLearning
----------------------------------------------------------------------------------------------------
注：此文章為原創，任何形式的轉載都請聯系作者獲得授權并注明出處！
若您覺得這篇文章還不錯，請點擊下方的【推薦】，非常感謝！
https://www.cnblogs.com/kiba/p/13258817.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/6418.html
標籤：C#
上一篇：C# 基于內容電影推薦專案（一）
下一篇：MSIL入門（二）通過物件看IL