迅雷 http

{

\"code\": 200,

\"title\": \"\",

\"content\": \"超文字傳輸協議（HTTP，HyperTextTransferProtocol)是互聯網上應用最為廣泛的一種網絡協議。所有的WWW檔案都必須遵守這個標準。設計HTTP最初的目的是為了提供一種釋出和接收HTML頁麵的方法。1960年美國人TedNelson構思了一種通過計算機處理文字資訊的方法，並稱之為超文字（hypertext）,這成為了HTTP超文字傳輸協議標準架構的發展根基。TedNelson組織協調萬維網協會（WorldWideWebConsortium）和互聯網工程工作小組（InternetEngineeringTaskForce）共同合作研究，最終釋出了一係列的RFC，其中著名的RFC2616定義了HTTP1.1。\\n\\nHTTP是一個客戶端和服務器端請求和應答的標準（TCP）。客戶端是終端用戶，服務器端是網站。通過使用Web瀏覽器、網絡爬蟲或者其它的工具，客戶端發起一個到服務器上指定（默認為80）的HTTP請求。（我們稱這個客戶端）叫用戶代理（useragent）。應答的服務器上存儲著（一些）資源，比如HTML檔案\\n\\nhttp和其他幾種網絡協議\\n\\n和圖像。（我們稱）這個應答服務器為源服務器（originserver）。在用戶代理和源服務器中間可能存在\\n\\nhttp和其他幾種網絡協議多箇中間層，比如代理，網關，或者隧道（tunnels）。儘管TCP\\/IP協議是互聯網上最流行的應用，HTTP協議並冇有規定必須使用它和（基於）它支援的層。事實上，HTTP可以在任何其他互聯網協議上，或者在其他網絡上實現。HTTP隻假定（其下層協議提供）可靠的傳輸，任何能夠提供這種保證的協議都可以被其使用。\\n\\n通常，由HTTP客戶端發起一個請求，建立一個到服務器指定（默認是80）的TCP連接。HTTP服務器則在那個監聽客戶端發送過來的請求。一旦收到請求，服務器（向客戶端）發回一個狀態行，比\\n\\nHTTP協議的網頁\\n\\n如\\\"HTTP\\/1.1200OK\\\"，和（響應的）訊息，訊息的訊息體可能是請求的檔案、錯誤訊息、或者其它一些資訊。\\n\\nHTTP協議的網頁\\n\\nHTTP使用TCP而不是UDP的原因在於（打開）一個網頁必須傳送很多數據，而TCP協議提供傳輸控製，按順序組織數據，和錯誤糾正。\\n\\n通過HTTP或者HTTPS協議請求的資源由統一資源標示符（UniformResourceIdentifiers）（或者，更準確一些，URLs）來標識。\\n\\n協議功能\\n\\nHTTP協議（HyperTextTransferProtocol，超文字傳輸協議）是用於從WWW服務器傳輸超文字到本地瀏覽器的傳輸協議。它可以使瀏覽器更加高效，使網絡傳輸減少。它不僅保證計算機正確快速地傳輸超文字文檔，還確定傳輸文檔中的哪一部分，以及哪部分內容首先顯示(如文字先於圖形)等。\\n\\nHTTP是客戶端瀏覽器或其他程式與Web服務器之間的應用層通訊協議。在Internet上的Web服務器上存放的都是超文字資訊，客戶機需要通過HTTP協議傳輸所要訪問的超文字資訊。HTTP包含命令和傳輸資訊，不僅可用於Web訪問，也可以用於其他因特網\\/內聯網應用係統之間的通訊，從而實現各類應用資源超媒體訪問的整合。\\n\\n我們在瀏覽器的地址欄裡輸入的網站地址叫做URL(UniformResourceLocator，統一資源定位符)。就像每\\n\\nhttp功用\\n\\n家每戶都有一個門牌地址一樣，每個網頁也都有一個Internet地址。當你在\\n\\nhttp功用瀏\\n\\n覽器的地址框中輸入一個URL或是單擊一個超級鏈接時，URL就確定了要瀏覽的地址。瀏覽器通過超文字傳輸協議(HTTP)，將Web服務器上站點的網頁代碼提取出來，並翻譯成漂亮的網頁。\\n\\n協議基礎\\n\\nHTTP（HyperTextTransportProtocol）是超文字傳輸協議的縮寫，它用於傳送WWW方式的數據，關於HTTP協議的詳細內容請參考RFC2616。HTTP協議采用了請求\\/響應模型。客戶端向服務器發送一個請求，請求頭包含請求的方法、URL、協議版本、以及包含請求修飾符、客戶資訊和內容的類似於MIME的訊息結構。服務器以一個狀態行作為響應，響應的內容包括訊息協議的版本，成功或者錯誤編碼加上包含服務器資訊、實體元資訊以及可能的實體內容。\\n\\n通常HTTP訊息包括客戶機向服務器的請求訊息和服務器向客戶機的響應訊息。這兩種類型的訊息由一個起始行，一個或者多個頭域，一個指示頭域結束的空行和可選的訊息體組成。HTTP的頭域包括通用頭，請求頭，響應頭和實體頭四個部分。每個頭域由一個域名，冒號（:）和域值三部分組成。域名是大小寫無關的，域值前可以新增任何數量的空格符，頭域可以被擴展為多行，在每行開始處，使用至少一個空格或製表符。\\n\\n通用頭域\\n\\n通用頭域包含請求和響應訊息都支援的頭域，通用頭域包含Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。對通用頭域的擴展要求通訊雙方都支援此擴展，如果存在不支援的通用頭域，一般將會作為實體頭域處理。下麵簡單介紹幾個在UPnP訊息中使用的通用頭域：\\n\\n1.Cache-Control頭域\\n\\nCache-Control指定請求和響應遵循的緩存機製。在請求訊息或響應訊息中設置Cache-Control並不會修改另一個訊息處理過程中的緩存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if-cached，響應訊息中的指令包括public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age。各個訊息中的指令含義如下：\\n\\nPublic指示響應可被任何緩存區緩存。\\n\\nhttp結構\\n\\nPrivate指示對於單個用戶的整個或部分響應訊息，不能被共享緩存處理。這允許服務器僅僅描述當用戶\\n\\nhttp結構的部\\n\\n分響應訊息，此響應訊息對於其他用戶的請求無效。\\n\\nno-cache指示請求或響應訊息不能緩存\\n\\nno-store用於防止重要的資訊被無意的釋出。在請求訊息中發送將使得請求和響應訊息都不使用緩存。\\n\\nmax-age指示客戶機可以接收生存期不大於指定時間（以秒為單位）的響應。\\n\\nmin-fresh指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。\\n\\nmax-stale指示客戶機可以接收超出超時期間的響應訊息。如果指定max-stale訊息的值，那麼客戶機可以接收超出超時期指定值之內的響應訊息。\\n\\nHTTPKeep-Alive\\n\\nKeep-Alive功能使客戶端到服務器端的連接持續有效，當出現對服務器的後繼請求時，Keep-Alive功能避免了建立或者重新建立連接。市場上的大部分Web服務器，包括iPlanet、IIS和Apache，都支援HTTPKeep-Alive。對於提供靜態內容的網站來說，這個功能通常很有用。但是，對於負擔較重的網站來說，這裡存在另外一個問題：雖然為客戶保留打開的連接有一定的好處，但它同樣影響了效能，因為在處理暫停期間，本來可以釋放的資源仍舊被占用。當Web服務器和應用服務器在同一台機器上運行時，Keep-Alive功能對資源利用的影響尤其突出。\\n\\nKeepAliveTime值控製TCP\\/IP嘗試驗證空閒連接是否完好的頻率。如果這段時間內冇有活動，則會發送保持活動信號。如果網絡工作正常，而且接收方是活動的，它就會響應。如果需要對丟失接收方敏感，換句話說，需要更快地發現丟失了接收方，請考慮減小這個值。如果長期不活動的空閒連接出現次數較多，而丟失接收方的情況出現較少，您可能會要提高該值以減少開銷。預設情況下，如果空閒連接7200000毫秒（2小時）內冇有活動，Windows就發送保持活動的訊息。通常，1800000毫秒是首選值，從而一半的已關閉連接會在30分鐘內被檢測到。KeepAliveInterval值定義瞭如果未從接收方收到保持活動訊息的響應，TCP\\/IP重複發送保持活動信號的頻率。當連續發送保持活動信號、但未收到響應的次數超出TcpMaxDataRetransmissions的值時，會放棄該連接。如果期望較長的響應時間，您可能需要提高該值以減少開銷。如果需要減少花在驗證接收方是否已丟失上的時間，請考慮減小該值或TcpMaxDataRetransmissions值。預設情況下，在未收到響應而重新發送保持活動的訊息之前，Windows會等待1000毫秒（1秒）。KeepAliveTime根據你的需要設置就行，比如10分鐘，注意要轉換成MS。XXX代表這個間隔值得大小。\\n\\n2.Date頭域\\n\\nDate頭域表示訊息發送的時間，時間的描述格式由rfc822定義。例如，Date:Mon,31Dec200104:25:57GMT。Date描述的時間表示世界標準時，換算成本地時間，需要知道用戶所在的時區。\\n\\n3.Pragma頭域\\n\\nPragma頭域用來包含實現特定的指令，最常用的是Pragma:no-cache。在HTTP\\/1.1協議中，它的含義和Cache-Control:no-cache相同。\\n\\n請求訊息\\n\\n請求訊息的第一行為下麵的格式：\\n\\nMethodSPRequest-URISPHTTP-VersionCRLFMethod表示對於Request-URI完成的方法，這個欄位是大小寫敏感的，包括OPTIONS、GET、HEAD、POST、PUT、DELETE、TRACE。方法GET和HEAD應該被所有的通用WEB服務器支援，其他所有方法的實現是可選的。GET方法取回由Request-URI標識的資訊。HEAD方法也是取回由Request-URI標識的資訊，隻是可以在響應時，不返回訊息體。POST方法可以請求服務器接收包含在請求中的實體資訊，可以用於提交表單，向新聞組、BBS、郵件群組和數據庫發送訊息。\\n\\nSP表示空格。Request-URI遵循URI格式，在此欄位為星號（*）時，說明請求並不用於某個特定的資源地址，而是用於服務器本身。HTTP-Version表示支援的HTTP版本，例如為HTTP\\/1.1。CRLF表示換行回車符。請\\n\\nhttp架構\\n\\n求頭域允許客戶端向服務器傳遞關於請求或者關於客戶機的附加信\\n\\nhttp架構息。請求頭\\n\\n域可能包含下列欄位Accept、Accept-Charset、Accept-Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If-Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、Proxy-Authorization、Range、Referer、User-Agent。對請求頭域的擴展要求通訊雙方都支援，如果存在不支援的請求頭域，一般將會作為實體頭域處理。\\n\\n典型的請求訊息：\\n\\nHost:download.*******.de\\n\\nAccept:*\\/*\\n\\nPragma:no-cache\\n\\nCache-Control:no-cache\\n\\nUser-Agent:Mozilla\\/4.04[en](Win95;I;Nav)\\n\\nRange:bytes=554554-\\n\\n上例第一行表示HTTP客戶端（可能是瀏覽器、下載程式）通過GET方法獲得指定URL下的檔案。棕色的部分表示請求頭域的資訊，綠色的部分表示通用頭部分。\\n\\n1.Host頭域\\n\\nHost頭域指定請求資源的Intenet主機和號，必須表示請求url的原始服務器或網關的位置。HTTP\\/1.1請求必須包含主機頭域，否則係統會以400狀態碼返回。\\n\\n2.Referer頭域\\n\\nReferer頭域允許客戶端指定請求uri的源資源地址，這可以允許服務器生成回退鏈表，可用來登陸、優化cache等。他也允許廢除的或錯誤的連接由於維護的目的被追蹤。如果請求的uri冇有自己的uri地址，Referer不能被髮送。如果指定的是部分uri地址，則此地址應該是一個相對地址。\\n\\n3.Range頭域\\n\\nRange頭域可以請求實體的一個或者多個子範圍。例如，\\n\\n表示頭500個字節：bytes=0-499\\n\\n表示第二個500字節：bytes=500-999\\n\\n表示最後500個字節：bytes=-500\\n\\n表示500字節以後的範圍：bytes=500-\\n\\n第一個和最後一個字節：bytes=0-0,-1\\n\\n同時指定幾個範圍：bytes=500-600,601-999\\n\\n但是服務器可以忽略此請求頭，如果無條件GET包含Range請求頭，響應會以狀態碼206（PartialContent）返回而不是以200（OK）。\\n\\n4.User-Agent頭域\\n\\nUser-Agent頭域的內容包含發出請求的用戶資訊。\\n\\n響應訊息\\n\\n響應訊息的第一行為下麵的格式：\\n\\nHTTP-VersionSPStatus-CodeSPReason-PhraseCRLF\\n\\nHTTP-Version表示支援的HTTP版本，例如為HTTP\\/1.1。Status-Code是一個三個數字的結果代碼。Reason-Phrase給Status-Code提供一個簡單的文字描述。Status-Code主要用於機器自動識彆，Reason-Phrase主要用於幫助用戶理解。Status-Code的第一個數字定義響應的類彆，後兩個數字冇有分類的作用。第一個數字可能取5個不同的值：\\n\\n1xx:資訊響應類，表示接收到請求並且繼續處理\\n\\n2xx:處理成功響應類，表示動作被成功接收、理解和接受\\n\\n3xx:重定向響應類，為了完成指定的動作，必須接受進一步處理\\n\\n4xx:客戶端錯誤，客戶請求包含語法錯誤或者是不能正確執行\\n\\n5xx:服務端錯誤，服務器不能正確執行一個正確的請求\\n\\n響應頭域允許服務器傳遞不能放在狀態行的附加資訊，這些域主要描述服務器的資訊和Request-URI進一步的資訊。響應頭域包含Age、Location、Proxy-Authenticate、Public、Retry-After、Server、Vary、Warning、WWW-Authenticate。對響應頭域的擴展要求通訊雙方都支援，如果存在不支援的響應頭域，一般將會作為實體頭域處理。\\n\\n典型的響應訊息：\\n\\nHTTP\\/1.0200OK\\n\\nDate:Mon,31Dec200104:25:57GMT\\n\\nServer:Apache\\/1.3.14(Unix)\\n\\nContent-type:text\\/html\\n\\nLast-modified:Tue,17Apr200106:46:28GMT\\n\\nEtag:\\\"a030f020ac7c01:1e9f\\\"\\n\\nContent-length:39725426\\n\\nContent-range:bytes55******\\/40279980\\n\\n上例第一行表示HTTP服務端響應一個GET方法。棕色的部分表示響應頭域的資訊，綠色的部分表示通用頭部分，紅色的部分表示實體頭域的資訊。\\n\\n1.Location響應頭\\n\\nLocation響應頭用於重定向接收者到一個新URI地址。\\n\\n2.Server響應頭\\n\\nServer響應頭包含處理請求的原始服務器的軟件資訊。此域能包含多個產品標識和註釋，產品標識一般按照重要性排序。\\n\\n實體資訊\\n\\n請求訊息和響應訊息都可以包含實體資訊，實體資訊一般由實體頭域和實體組成。實體頭域包含關於實體的原資訊，實體頭包括Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。extension-header允許客戶端定義新的實體頭，但是這些域可能無法被接受方識彆。實體可以是一個經過編碼的字節流，它的編碼方式由Content-Encoding或Content-Type定義，它的長度由Content-Length或Content-Range定義。\\n\\n1.Content-Type實體頭\\n\\nContent-Type實體頭用於向接收方指示實體的介質類型，指定HEAD方法送到接收方的實體介質類型，或GET方法發送的請求介質類型\\n\\n2.Content-Range實體頭\\n\\nContent-Range實體頭用於指定整個實體中的一部分的插入位置，他也指示了整個實體的長度。在服務器向客戶返回一個部分響應，它必須描述響應覆蓋的範圍和整個實體長度。一般格式：\\n\\nContent-Range:bytes-unitSPfirst-byte-pos-last-byte-pos\\/entity-legth\\n\\n例如，傳送頭500個字節次欄位的形式：Content-Range:bytes0-499\\/1234如果一個http訊息包含此節（例如，對範圍請求的響應或對一係列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。\\n\\n3.Last-modified實體頭\\n\\nLast-modified實體頭指定服務器上儲存內容的最後修訂時間。\\n\\n例如，傳送頭500個字節次欄位的形式：Content-Range:bytes0-499\\/1234如果一個http訊息包含此節（例如，對範圍請求的響應或對一係列範圍的重疊請求），Content-Range表示傳送的範圍，Content-Length表示實際傳送的字節數。\\n\\n運作方式\\n\\n在WWW中，“客戶”與“服務器”是一個相對的概念，隻存在於一個特定的連接期間，即在某個連接中的客戶在另一個連接中可能作為服務器。基於HTTP協議的客戶\\/服務器模式的資訊交換過程，它分四個過程：建立連接、發送請求資訊、發送響應資訊、關閉連接。\\n\\nHTTP協議是基於請求\\/響應範式的。一個客戶機與服務器建立連接後，發送一個請求給服務器，請求方式的格式為，統一資源標識符、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。服務器接到請求後，給予相應的響應資訊，其格式為一個狀態行包括資訊的協議版本號、一個成功或錯誤的代碼，後邊\\n\\nhttp運作方式的一種\\n\\n是MIME資訊包括服務器資訊、實體資訊和可能的內容。\\n\\nhttp運作方式的一種其實簡單說就是任何\\n\\n服務器除了包括HTML檔案以外，還有一個HTTP駐留程式，用於響應用戶請求。你的瀏覽器是HTTP客戶，向服務器發送請求，當瀏覽器中輸入了一個開始檔案或點擊了一個超級鏈接時，瀏覽器就向服務器發送了HTTP請求，此請求被送往由IP地址指定的URL。駐留程式接收到請求，在進行必要的操作後回送所要求的檔案。在這一過程中，在網絡上發送和接收的數據已經被分成一個或多個數據包（packet），每個數據包包括：要傳送的數據；控製資訊，即告訴網絡怎樣處理數據包。TCP\\/IP決定了每個數據包的格式。如果事先不告訴你，你可能不會知道資訊被分成用於傳輸和再重新組合起來的許多小塊。\\n\\n許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理(UA)和源服務器(O)之間通過一個單獨的連接來完成。\\n\\n當一個或多箇中介出現在請求\\/響應鏈中時，情況就變得複雜一些。中介由三種：代理(Proxy)、網關(Gateway)和通道(Tunnel)。一個代理根據URI的絕對格式來接受請求，重寫全部或部分訊息，通過URI的標識把已格式化過的請求發送到服務器。網關是一個接收代理，作為一些其它服務器的上層，並且如果必須的話，可以把請求翻譯給下層的服務器協議。一個通道作為不改變訊息的兩個連接之間的中繼點。當通訊需要通過一箇中介(例如：防火牆等)或者是中介不能識彆訊息的內容時，通道經常被使用。\\n\\n報文格式\\n\\nHTTP報文由從客戶機到服務器的請求和從服務器到客戶機的響應構成。請求報文格式如下：\\n\\n請求行－通用資訊頭－請求頭－實體頭－報文主體\\n\\n請求行以方法欄位開始，後麵分彆是URL欄位和HTTP協議版本欄位，並以CRLF結尾。SP是分隔符。除了在最後的CRLF序列中CF和LF是必需的之外，其他都可以不要。有關通用資訊頭，請求頭和實體頭方麵的具體內容可以參照相關檔案。\\n\\n應答報文格式如下：\\n\\n狀態行－通用資訊頭－響應頭－實體頭－報文主體\\n\\n狀態碼元由3位數字組成，表示請求是否被理解或被滿足。原因分析是對原文的狀態碼作簡短的描述，狀態碼用來支援自動操作，而原因分析用來供用戶使用。客戶機無需用來檢查或顯示語法。有關通用資訊頭，響應頭和實體頭方麵的具體內容可以參照相關檔案。\\n\\n工作原理\\n\\n一次HTTP操作稱為一個事務，其工作過程可分為四步：\\n\\n首先客戶機與服務器需要建立連接。隻要單擊某個超級鏈接，HTTP的工作就開始了。\\n\\n建立連接後，客戶機發送一個請求給服務器，請求方式的格式為：統一資源標識符（URL）、協議版本號，後邊是MIME資訊包括請求修飾符、客戶機資訊和可能的內容。\\n\\n服務器接到請求後，給予相應的響應資訊，其格式為一個狀態行，包括資訊的協議版本號、一個成功或錯誤的代碼，後邊是MIME資訊包括服務器資訊、實體資訊和可能的內容。\\n\\nhttp工作流程圖\\n\\n客戶端接收服務器所返回的資訊通過瀏覽器顯示在用戶的顯示屏上，然後客\\n\\nhttp工作流程圖戶機與服務器斷開連接。\\n\\n如果在以上過程中的某一步出現錯誤，那麼產生錯誤的資訊將返回到客戶端，由顯示屏輸出。對於用戶來說，這些過程是由HTTP自己完成的，用戶隻要用鼠標點擊，等待資訊顯示就可以了。\\n\\n許多HTTP通訊是由一個用戶代理初始化的並且包括一個申請在源服務器上資源的請求。最簡單的情況可能是在用戶代理和服務器之間通過一個單獨的連接來完成。在Internet上，HTTP通訊通常發生在TCP\\/IP連接之上。預設是TCP80，但其它的也是可用的。但這並不預示著HTTP協議在Internet或其它網絡的其它協議之上才能完成。HTTP隻預示著一個可靠的傳輸。\\n\\n這個過程就好像我們打電話訂貨一樣，我們可以打電話給商家，告訴他我們需要什麼規格的商品，然後商家再告訴我們什麼商品有貨，什麼商品缺貨。這些，我們是通過電話線用電話聯絡（HTTP是通過TCP\\/IP），當然我們也可以通過傳真，隻要商家那邊也有傳真。\\n\\n超文字傳輸協議已經演化出了很多版本，它們中的大部分都是向下相容的。在RFC2145中描述了HTTP\\n\\n配置http通行證版本\\n\\n號的用法。客戶端在請求的開始告訴服務器它采用的協議版本號，而後者則在響應中采用相同或者更早的協議版本。\\n\\n0.9已過時。隻接受GET一種請求方法，冇有在通訊中指定版本號，且不支援請求頭。由於該版本不支援POST方法，所以客戶端無法向服務器傳遞太多資訊。\\n\\nHTTP\\/1.0這是第一個在通訊中指定版本號的HTTP協議版本，至今仍被廣泛采用，特彆是在代理服務器中。\\n\\nHTTP\\/1.1當前版本。持久連接被默認采用，並能很好地配合代理服務器工作。還支援以管道方式同時發送多個請求，以便降低線路負載，提高傳輸速度。\\n\\nHTTP\\/1.1相較於HTTP\\/1.0協議的區彆主要體現在：\\n\\n1緩存處理\\n\\n2帶寬優化及網絡連接的使用\\n\\n3錯誤通知的管理\\n\\n4訊息在網絡中的發送\\n\\n5互聯網地址的維護\\n\\n6安全性及完整性\\n\\n天網Maze是北京大學網絡實驗室開發的一款資源和功能非常強大的PIC（PersonalInformationCenter個人資訊中心）檔案係統。截至到2005年10月，天網Maze已有註冊用戶220萬，同時最高在線用戶數超過10萬。\\n\\n天網Maze的特點\\n\\n天網互聯公司首先推出這個PIC概念，目的是為了和其他P2P軟件區彆開（詳情請參看天網Maze與其它BT軟件的異同）。相比其他P2P軟件，天網Maze更加註重的是以人為本，誠信交流的原則。具體體現在：機製方麵，我們有積分原則和排隊策略，用以鼓勵天網Maze用戶儘可能地與他人共享其資源，而處罰規則，用以對流傳在天網Maze上的各類非法資源進行處理，擁護國家對中國互聯網上的有關法律規章，維護互聯網上的合法、正常的次序，即在推崇個性化的同時，規範其個性化在天網Maze上的發展；技術方麵，我們努力在天網Maze上實現檔案的“所見即所得”，讓更多精彩的、熱門的檔案以最快的速度呈獻在廣大天網Maze用戶麵前；資源方麵：在天網Maze裡麵，有數以億計的影視，音樂，小說等娛樂資源。不僅如此，因為在天網Maze的共享資源裡麵具有極其多的學術檔案，論文可供查詢和下載，這也是天網Maze在教育網內的風行的原因，天網Maze還是個交友和社區化的平台，能把您周圍和您有共同愛好的天網Maze用戶聚集到一起來；功能方麵：天網Maze集檔案的共享、查詢、下載為一身，既是網上資源搜尋的強力引擎，也是資源下載的利器，您不僅可以通過天網Maze的共享功能直接下載，還可以像其它BT軟件一樣通過“種子”的釋出達到資源共享及下載的目的。\\n\\nMaze是北京大學深圳研究生院幾位碩士研究生在2003年暑假的開發成果，目的是解決當前FTP服務器的缺陷以及它所導致的在FTP搜尋引擎內找到資源卻無法有效下載的問題，為廣大網友提供一種檔案共享的新方法、檔案下載的新途徑。\\n\\n\"

}