面試知識點八：網絡

79.http 響應碼 301 和 302 表明的是什麼？有什麼區別？

80.forward 和 redirect 的區別？

81.簡述 tcp 和 udp的區別？

82.tcp 爲何要三次握手，兩次不行嗎？爲何？

83.說一下 tcp 粘包是怎麼產生的？

84.OSI 的七層模型都有哪些？

85.get 和 post 請求有哪些區別？

86.如何實現跨域？

87.說一下 JSONP 實現原理？

 

79.http 響應碼 301 和 302 表明的是什麼？有什麼區別？

官方的比較簡潔的說明：

        301 redirect: 301 表明永久性轉移(Permanently Moved)

        302 redirect: 302 表明暫時性轉移(Temporarily Moved )

詳細來講，301和302狀態碼都表示重定向，就是說瀏覽器在拿到服務器返回的這個狀態碼後會自動跳轉到一個新的URL地址，這個地址能夠從響應的Location首部中獲取（用戶看到的效果就是他輸入的地址A瞬間變成了另外一個地址B）——這是它們的共同點。他們的不一樣在於。301表示舊地址A的資源已經被永久地移除了（這個資源不可訪問了），搜索引擎在抓取新內容的同時也將舊的網址交換爲重定向以後的網址；302表示舊地址A的資源還在（仍然能夠訪問），這個重定向只是臨時地從舊地址A跳轉到地址B，搜索引擎會抓取新的內容而保存舊的網址。

　　http狀態碼301和302詳解及區別

80.forward 和 redirect 的區別？

　　在學習Servlet和JSP時，常常會使用到forward和redirect，咱們先來看這二者在Servlet中的調用方式：

　　1.forward

　　request.getRequestDispatcher("new.jsp").forward(request, response);   //轉發到new.jsp

　　2.redirect

　　response.sendRedirect("new.jsp");   //重定向到new.jsp

　　很明顯一個是用request對象調用，一個是用response對象調用，那麼，這二者有什麼區別呢？

　　1、數據共享方面

　　forward:轉發頁面和轉發到的頁面能夠共享request裏面的數據
　　redirect:不能共享數據

　　2、地址欄顯示方面

　　forward是服務器請求資源,服務器直接訪問目標地址的URL,把那個URL的響應內容讀取過來,而後把這些內容再發給瀏覽器.瀏覽器根本不知道服務器發送的內容從哪裏來的,因此它的地址欄仍是原來的地址.
　　redirect是服務端根據邏輯,發送一個狀態碼,告訴瀏覽器從新去請求那個地址.因此地址欄顯示的是新的URL.

　　3、本質區別

　　轉發是服務器行爲，重定向是客戶端行爲。爲何這樣說呢，這就要看兩個動做的工做流程： 

　　轉發過程：客戶瀏覽器發送http請求--->web服務器接受此請求--->調用內部的一個方法在容器內部完成請求處理和轉發動做--->將目標資源 發送給客戶；在這裏，轉發的路徑必須是同一個web容器下的url，其不能轉向到其餘的web路徑上去，中間傳遞的是本身的容器內的request。在客 戶瀏覽器路徑欄顯示的仍然是其第一次訪問的路徑，也就是說客戶是感受不到服務器作了轉發的。轉發行爲是瀏覽器只作了一次訪問請求。 

　　重定向過程：客戶瀏覽器發送http請求--->web服務器接受後發送302狀態碼響應及對應新的location給客戶瀏覽器--->客戶瀏覽器發現 是302響應，則自動再發送一個新的http請求，請求url是新的location地址--->服務器根據此請求尋找資源併發送給客戶。在這裏 location能夠重定向到任意URL，既然是瀏覽器從新發出了請求，則就沒有什麼request傳遞的概念了。在客戶瀏覽器路徑欄顯示的是其重定向的 路徑，客戶能夠觀察到地址的變化的。重定向行爲是瀏覽器作了至少兩次的訪問請求的。 　　

　　重定向，實際上是兩次request:第一次，客戶端request A,服務器響應，並response回來，告訴瀏覽器，你應該去B。這個時候IE能夠看到地址變了，並且歷史的回退按鈕也亮了。重定向能夠訪問本身web應用之外的資源。在重定向的過程當中，傳輸的信息會被丟失。 

　　4、從效率來講：

　　forword效率高，而redirect效率低

　　5、從請求的次數來講：

　　forword只有一次請求；而redirect有兩次請求

forward（轉發）與redirect（重定向）的區別

forward和redirect的區別是什麼？

81.簡述 tcp 和 udp的區別？

　　TCP/IP協議是一個協議簇。裏面包括不少協議的。UDP只是其中的一個。之因此命名爲TCP/IP協議，由於TCP,IP協議是兩個很重要的協議，就用他兩命名了。
TCP/IP協議集包括應用層,傳輸層，網絡層，網絡訪問層。

　　TCP（Transmission Control Protocol，傳輸控制協議）是面向鏈接的協議，也就是說，在收發數據前，必須和對方創建可靠的鏈接。一個TCP鏈接必需要通過三次「對話」才能創建起來，其中的過程很是複雜，只簡單的描述下這三次對話的簡單過程：主機A向主機B發出鏈接請求數據包：「我想給你發數據，能夠嗎？」，這是第一次對話；主機B向主機A發送贊成鏈接和要求同步（同步就是兩臺主機一個在發送，一個在接收，協調工做）的數據包：「能夠，你何時發？」，這是第二次對話；主機A再發出一個數據包確認主機B的要求同步：「我如今就發，你接着吧！」，這是第三次對話。三次「對話」的目的是使數據包的發送和接收同步，通過三次「對話」以後，主機A才向主機B正式發送數據。

　　UDP（User Data Protocol，用戶數據報協議）
（1） UDP是一個非鏈接的協議，傳輸數據以前源端和終端不創建鏈接，當它想傳送時就簡單地去抓取來自應用程序的數據，並儘量快地把它扔到網絡上。在發送端，UDP傳送數據的速度僅僅是受應用程序生成數據的速度、計算機的能力和傳輸帶寬的限制；在接收端，UDP把每一個消息段放在隊列中，應用程序每次從隊列中讀一個消息段。
（2） 因爲傳輸數據不創建鏈接，所以也就不須要維護鏈接狀態，包括收發狀態等，所以一臺服務機可同時向多個客戶機傳輸相同的消息。

　　小結TCP與UDP的區別：
　　1.基於鏈接與無鏈接；
　　2.對系統資源的要求（TCP較多，UDP少）；
　　3.UDP程序結構較簡單；
　　4.流模式與數據報模式 ；
　　5.TCP保證數據正確性，UDP可能丟包，TCP保證數據順序，UDP不保證。

　　TCP和UDP的區別（轉）

82.tcp 爲何要三次握手，兩次不行嗎？爲何？

　　傳輸層創建了主機端到端的連接，傳輸層的做用是爲上層協議提供端到端的可靠和透明的數據傳輸服務，包括處理差錯控制和流量控制等問題。該層向高層屏蔽了下層數據通訊的細節，使高層用戶看到的只是在兩個傳輸實體間的一條主機到主機的、可由用戶控制和設定的、可靠的數據通路。咱們一般說的，TCP UDP就是在這一層。端口號既是這裏的「端」。

一、三次握手

（1）三次握手的詳述

首先Client端發送鏈接請求報文，Server段接受鏈接後回覆ACK報文，併爲此次鏈接分配資源。Client端接收到ACK報文後也向Server段發生ACK報文，並分配資源，這樣TCP鏈接就創建了。

 

 最初兩端的TCP進程都處於CLOSED關閉狀態，A主動打開鏈接，而B被動打開鏈接。（A、B關閉狀態CLOSED——B收聽狀態LISTEN——A同步已發送狀態SYN-SENT——B同步收到狀態SYN-RCVD——A、B鏈接已創建狀態ESTABLISHED）

• B的TCP服務器進程先建立傳輸控制塊TCB，準備接受客戶進程的鏈接請求。而後服務器進程就處於LISTEN（收聽）狀態，等待客戶的鏈接請求。如有，則做出響應。
• 1）第一次握手：A的TCP客戶進程也是首先建立傳輸控制塊TCB，而後向B發出鏈接請求報文段，（首部的同步位SYN=1，初始序號seq=x），（SYN=1的報文段不能攜帶數據）但要消耗掉一個序號，此時TCP客戶進程進入SYN-SENT（同步已發送）狀態。
• 2）第二次握手：B收到鏈接請求報文段後，如贊成創建鏈接，則向A發送確認，在確認報文段中（SYN=1，ACK=1，確認號ack=x+1，初始序號seq=y），測試TCP服務器進程進入SYN-RCVD（同步收到）狀態；
• 3）第三次握手：TCP客戶進程收到B的確認後，要向B給出確認報文段（ACK=1，確認號ack=y+1，序號seq=x+1）（初始爲seq=x，第二個報文段因此要+1），ACK報文段能夠攜帶數據，不攜帶數據則不消耗序號。TCP鏈接已經創建，A進入ESTABLISHED（已創建鏈接）。
• 當B收到A的確認後，也進入ESTABLISHED狀態。

（2）總結三次握手過程：

• 第一次握手：起初兩端都處於CLOSED關閉狀態，Client將標誌位SYN置爲1，隨機產生一個值seq=x，並將該數據包發送給Server，Client進入SYN-SENT狀態，等待Server確認；
• 第二次握手：Server收到數據包後由標誌位SYN=1得知Client請求創建鏈接，Server將標誌位SYN和ACK都置爲1，ack=x+1，隨機產生一個值seq=y，並將該數據包發送給Client以確認鏈接請求，Server進入SYN-RCVD狀態，此時操做系統爲該TCP鏈接分配TCP緩存和變量；
• 第三次握手：Client收到確認後，檢查ack是否爲x+1，ACK是否爲1，若是正確則將標誌位ACK置爲1，ack=y+1，而且此時操做系統爲該TCP鏈接分配TCP緩存和變量，並將該數據包發送給Server，Server檢查ack是否爲y+1，ACK是否爲1，若是正確則鏈接創建成功，Client和Server進入ESTABLISHED狀態，完成三次握手，隨後Client和Server就能夠開始傳輸數據。

起初A和B都處於CLOSED狀態——B建立TCB，處於LISTEN狀態，等待A請求——A建立TCB，發送鏈接請求（SYN=1，seq=x），進入SYN-SENT狀態——B收到鏈接請求，向A發送確認（SYN=ACK=1，確認號ack=x+1，初始序號seq=y），進入SYN-RCVD狀態——A收到B的確認後，給B發出確認（ACK=1，ack=y+1，seq=x+1），A進入ESTABLISHED狀態——B收到A的確認後，進入ESTABLISHED狀態。

TCB傳輸控制塊Transmission Control Block，存儲每個鏈接中的重要信息，如TCP鏈接表，到發送和接收緩存的指針，到重傳隊列的指針，當前的發送和接收序號。

（3）爲何A還要發送一次確認呢？能夠二次握手嗎？

　　答：主要爲了防止已失效的鏈接請求報文段忽然又傳送到了B，於是產生錯誤。如A發出鏈接請求，但因鏈接請求報文丟失而未收到確認，因而A再重傳一次鏈接請求。後來收到了確認，創建了鏈接。數據傳輸完畢後，就釋放了鏈接，A工發出了兩個鏈接請求報文段，其中第一個丟失，第二個到達了B，可是第一個丟失的報文段只是在某些網絡結點長時間滯留了，延誤到鏈接釋放之後的某個時間纔到達B，此時B誤認爲A又發出一次新的鏈接請求，因而就向A發出確認報文段，贊成創建鏈接，不採用三次握手，只要B發出確認，就創建新的鏈接了，此時A不理睬B的確認且不發送數據，則B一致等待A發送數據，浪費資源。

TCP三次握手和四次揮手過程

 

83.說一下 tcp 粘包是怎麼產生的？

1 什麼是粘包現象

　　TCP粘包是指發送方發送的若干包數據到接收方接收時粘成一包，從接收緩衝區看，後一包數據的頭緊接着前一包數據的尾。

2 爲何出現粘包現象

　　（1）發送方緣由

　　咱們知道，TCP默認會使用Nagle算法。而Nagle算法主要作兩件事：1）只有上一個分組獲得確認，纔會發送下一個分組；2）收集多個小分組，在一個確認到來時一塊兒發送。

　　因此，正是Nagle算法形成了發送方有可能形成粘包現象。

　　（2）接收方緣由

　　TCP接收到分組時，並不會馬上送至應用層處理，或者說，應用層並不必定會當即處理；實際上，TCP將收到的分組保存至接收緩存裏，而後應用程序主動從緩存裏讀收到的分組。這樣一來，若是TCP接收分組的速度大於應用程序讀分組的速度，多個包就會被存至緩存，應用程序讀時，就會讀到多個首尾相接粘到一塊兒的包。

3 何時須要處理粘包現象

　　（1）若是發送方發送的多個分組原本就是同一個數據的不一樣部分，好比一個很大的文件被分紅多個分組發送，這時，固然不須要處理粘包的現象；

　　（2）但若是多個分組本絕不相干，甚至是並列的關係，咱們就必定要處理粘包問題了。好比，我當時要接收的每一個分組都是一個有固定格式的商品信息，若是不處理粘包問題，每一個讀進來的分組我只會處理最前邊的那個商品，後邊的就會被丟棄。這顯然不是我要的結果。

4 如何處理粘包現象

　　（1）發送方

　　對於發送方形成的粘包現象，咱們能夠經過關閉Nagle算法來解決，使用TCP_NODELAY選項來關閉Nagle算法。

　　（2）接收方

　　遺憾的是TCP並無處理接收方粘包現象的機制，咱們只能在應用層進行處理。

　　（3）應用層處理

　　應用層的處理簡單易行！而且不只能夠解決接收方形成的粘包問題，還能解決發送方形成的粘包問題。

　　解決方法就是循環處理：應用程序在處理從緩存讀來的分組時，讀完一條數據時，就應該循環讀下一條數據，直到全部的數據都被處理；可是如何判斷每條數據的長度呢？

　　兩種途徑：

　　　1）格式化數據：每條數據有固定的格式（開始符、結束符），這種方法簡單易行，但選擇開始符和結束符的時候必定要注意每條數據的內部必定不能出現開始符或結束符；

　　　2）發送長度：發送每條數據的時候，將數據的長度一併發送，好比能夠選擇每條數據的前4位是數據的長度，應用層處理時能夠根據長度來判斷每條數據的開始和結束。

　　當時在作購物車的時候，我最開始的作法是設置開始符（0x7e）和結束符（0xe7），但在測試大量數據的時候，發現了數據異常。正如我所猜想，在調試過程當中發現某些數據內部包含了它們。由於要處理的數據是量很是龐大，爲作到萬無一失，最後我採用了發送長度的方式。再也沒有由於粘包而出過問題。

　　TCP的粘包現象

84.OSI 的七層模型都有哪些？

一、OSI的來源

        OSI（Open System Interconnect），即開放式系統互聯。 通常都叫OSI參考模型，是ISO（國際標準化組織）組織在1985年研究的網絡互連模型。

        ISO爲了更好的使網絡應用更爲普及，推出了OSI參考模型。其含義就是推薦全部公司使用這個規範來控制網絡。這樣全部公司都有相同的規範，就能互聯了。

二、OSI七層模型的劃分

       OSI定義了網絡互連的七層框架（物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層），即ISO開放互連繫統參考模型。以下圖。

        每一層實現各自的功能和協議，並完成與相鄰層的接口通訊。OSI的服務定義詳細說明了各層所提供的服務。某一層的服務就是該層及其下各層的一種能力，它經過接口提供給更高一層。各層所提供的服務與這些服務是怎麼實現的無關。

    

 

三、各層功能定義

        這裏咱們只對OSI各層進行功能上的大概闡述，不詳細深究，由於每一層實際都是一個複雜的層。後面我也會根據我的方向展開部分層的深刻學習。這裏咱們就大概瞭解一下。咱們從最頂層——應用層 開始介紹。 整個過程以公司A和公司B的一次商業報價單發送爲例子進行講解。

<1>    應用層

        OSI參考模型中最靠近用戶的一層，是爲計算機用戶提供應用接口，也爲用戶直接提供各類網絡服務。咱們常見應用層的網絡服務協議有：HTTP，HTTPS，FTP，POP三、SMTP等。

         實際公司A的老闆就是咱們所述的用戶，而他要發送的商業報價單，就是應用層提供的一種網絡服務，固然，老闆也能夠選擇其餘服務，好比說，發一份商業合同，發一份詢價單，等等。

 

<2>    表示層

        表示層提供各類用於應用層數據的編碼和轉換功能,確保一個系統的應用層發送的數據能被另外一個系統的應用層識別。若是必要，該層可提供一種標準表示形式，用於將計算機內部的多種數據格式轉換成通訊中採用的標準表示形式。數據壓縮和加密也是表示層可提供的轉換功能之一。

        因爲公司A和公司B是不一樣國家的公司，他們之間的商定統一用英語做爲交流的語言，因此此時表示層（公司的文祕），就是將應用層的傳遞信息轉翻譯成英語。同時爲了防止別的公司看到，公司A的人也會對這份報價單作一些加密的處理。這就是表示的做用，將應用層的數據轉換翻譯等。

<3>    會話層

        會話層就是負責創建、管理和終止表示層實體之間的通訊會話。該層的通訊由不一樣設備中的應用程序之間的服務請求和響應組成。      

          會話層的同事拿到表示層的同事轉換後資料，（會話層的同事相似公司的外聯部），會話層的同事那裏可能會掌握本公司與其餘好多公司的聯繫方式，這裏公司就是實際傳遞過程當中的實體。他們要管理本公司與外界好多公司的聯繫會話。當接收到表示層的數據後，會話層將會創建並記錄本次會話，他首先要找到公司B的地址信息，而後將整份資料放進信封，並寫上地址和聯繫方式。準備將資料寄出。等到肯定公司B接收到此份報價單後，這次會話就算結束了，外聯部的同事就會終止這次會話。

<4>   傳輸層

        傳輸層創建了主機端到端的連接，傳輸層的做用是爲上層協議提供端到端的可靠和透明的數據傳輸服務，包括處理差錯控制和流量控制等問題。該層向高層屏蔽了下層數據通訊的細節，使高層用戶看到的只是在兩個傳輸實體間的一條主機到主機的、可由用戶控制和設定的、可靠的數據通路。咱們一般說的，TCP UDP就是在這一層。端口號既是這裏的「端」。

         傳輸層就至關於公司中的負責快遞郵件收發的人，公司本身的投遞員，他們負責將上一層的要寄出的資料投遞到快遞公司或郵局。

<5>   網絡層

       本層經過IP尋址來創建兩個節點之間的鏈接，爲源端的運輸層送來的分組，選擇合適的路由和交換節點，正確無誤地按照地址傳送給目的端的運輸層。就是一般說的IP層。這一層就是咱們常常說的IP協議層。IP協議是Internet的基礎。

         網絡層就至關於快遞公司龐大的快遞網絡，全國不一樣的集散中心，好比說，從深圳發往北京的順豐快遞（陸運爲例啊，空運好像直接就飛到北京了），首先要到順豐的深圳集散中心，從深圳集散中心再送到武漢集散中心，從武漢集散中心再寄到北京順義集散中心。這個每一個集散中心，就至關於網絡中的一個IP節點。

<6>   數據鏈路層 

        將比特組合成字節,再將字節組合成幀,使用鏈路層地址 (以太網使用MAC地址)來訪問介質,並進行差錯檢測。

     數據鏈路層又分爲2個子層：邏輯鏈路控制子層（LLC）和媒體訪問控制子層（MAC）。

        MAC子層處理CSMA/CD算法、數據出錯校驗、成幀等；LLC子層定義了一些字段使上次協議能共享數據鏈路層。 在實際使用中，LLC子層並不是必需的。

        這個沒找到合適的例子

<7>  物理層     

        實際最終信號的傳輸是經過物理層實現的。經過物理介質傳輸比特流。規定了電平、速度和電纜針腳。經常使用設備有（各類物理設備）集線器、中繼器、調制解調器、網線、雙絞線、同軸電纜。這些都是物理層的傳輸介質。

          快遞寄送過程當中的交通工具，就至關於咱們的物理層，例如汽車，火車，飛機，船。

 

OSI七層模型與TCP/IP五層模型

85.get 和 post 請求有哪些區別？

什麼是 HTTP？

超文本傳輸協議（HTTP）的設計目的是保證客戶機與服務器之間的通訊。

HTTP 的工做方式是客戶機與服務器之間的請求-應答協議。

web 瀏覽器多是客戶端，而計算機上的網絡應用程序也可能做爲服務器端。

舉例：客戶端（瀏覽器）向服務器提交 HTTP 請求；服務器向客戶端返回響應。響應包含關於請求的狀態信息以及可能被請求的內容。

兩種 HTTP 請求方法：GET 和 POST

在客戶機和服務器之間進行請求-響應時，兩種最常被用到的方法是：GET 和 POST。

• GET - 從指定的資源請求數據。
• POST - 向指定的資源提交要被處理的數據

下面的表格比較了兩種 HTTP 方法：GET 和 POST。

	GET	POST
後退按鈕/刷新	無害	數據會被從新提交（瀏覽器應該告知用戶數據會被從新提交）。
書籤	可收藏爲書籤	不可收藏爲書籤
緩存	能被緩存	不能緩存
編碼類型	application/x-www-form-urlencoded	application/x-www-form-urlencoded 或 multipart/form-data。爲二進制數據使用多重編碼。
歷史	參數保留在瀏覽器歷史中。	參數不會保存在瀏覽器歷史中。
對數據長度的限制	是的。當發送數據時，GET 方法向 URL 添加數據；URL 的長度是受限制的（URL 的最大長度是 2048 個字符）。	無限制。
對數據類型的限制	只容許 ASCII 字符。	沒有限制。也容許二進制數據。
安全性	與 POST 相比，GET 的安全性較差，由於所發送的數據是 URL 的一部分。 在發送密碼或其餘敏感信息時毫不要使用 GET ！	POST 比 GET 更安全，由於參數不會被保存在瀏覽器歷史或 web 服務器日誌中。
可見性	數據在 URL 中對全部人都是可見的。	數據不會顯示在 URL 中。

HTTP 方法：GET 對比 POST

進階版：也談 GET 和 POST 的區別

86.如何實現跨域？

什麼是跨域？

　　跨域，指的是瀏覽器不能執行其餘網站的腳本。它是由瀏覽器的同源策略形成的，是瀏覽器施加的安全限制。

　　所謂同源是指，域名，協議，端口均相同，不明白不要緊，舉個栗子：

　　http://www.123.com/index.html 調用 http://www.123.com/server.php （非跨域）

　　http://www.123.com/index.html 調用 http://www.456.com/server.php （主域名不一樣:123/456，跨域）

　　http://abc.123.com/index.html 調用 http://def.123.com/server.php （子域名不一樣:abc/def，跨域）

　　http://www.123.com:8080/index.html 調用 http://www.123.com:8081/server.php （端口不一樣:8080/8081，跨域）

　　http://www.123.com/index.html 調用 https://www.123.com/server.php （協議不一樣:http/https，跨域）

　　請注意：localhost和127.0.0.1雖然都指向本機，但也屬於跨域。

　　瀏覽器執行javascript腳本時，會檢查這個腳本屬於哪一個頁面，若是不是同源頁面，就不會被執行。

解決辦法：

　　一、JSONP：

　　JSONP 是服務器與客戶端跨源通訊的經常使用方法。最大特色就是簡單適用，兼容性好（兼容低版本IE），缺點是隻支持get請求，不支持post請求。

　　核心思想：網頁經過添加一個<script>元素，向服務器請求 JSON 數據，服務器收到請求後，將數據放在一個指定名字的回調函數的參數位置傳回來。

<script src="http://test.com/data.php?callback=dosomething"></script>
// 向服務器test.com發出請求，該請求的查詢字符串有一個callback參數，用來指定回調函數的名字

// 處理服務器返回回調函數的數據
<script type="text/javascript">
function dosomething(data){
//處理得到的數據
}
</script>

　　二、代理：

　　例如www.123.com/index.html須要調用www.456.com/server.php，能夠寫一個接口www.123.com/server.php，由這個接口在後端去調用www.456.com/server.php並拿到返回值，而後再返回給index.html，這就是一個代理的模式。至關於繞過了瀏覽器端，天然就不存在跨域問題。

　　三、PHP端修改header（XHR2方式）

　　在php接口腳本中加入如下兩句便可：

　　header('Access-Control-Allow-Origin:*');//容許全部來源訪問

　　header('Access-Control-Allow-Method:POST,GET');//容許訪問的方式

　　參考：什麼是跨域？怎麼解決跨域問題？

　　　　　什麼是跨域？跨域解決方法

　　　　　不要再問我跨域的問題了

87.說一下 JSONP 實現原理？

　　參考：jsonp原理詳解——終於搞清楚jsonp是啥了

　　　　　完全弄懂jsonp原理及實現方法