由於HTTP協議是基於請求/響應範式的（相當於客戶機/服務器）。一個客戶機與服務器建立連接後，發送一個請求給服務器，請求方式的格式爲：統一資源標識符(URL)、協議版本號，後邊是MIME信息包括請求修飾符、客戶機信息和可能的內容。服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行，包括信息的協議版本號、一個成功或錯誤的代碼，後邊是MIME信息包括服務器信息、實體信息和可能的內容。
留意這行文字：“服務器接到請求後，給予相應的響應信息，其格式爲一個狀態行”，這是HTTP協議的一個重要特性，我們可以做個實驗：
用TELNET或任何一個能建立HTTP連接的程序連接到某服務器的80端口，手工輸入：
GET /index.htm HTTP/1.0（必須確保這個工具能自動產生兩個換行符，否則服務器會認爲你沒有輸入完全！）
如果index.htm存在，你會看到類似以下的報文：
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Content-Location: http://www.******.com/index.htm
Date: Sat, 20 Jul 2002 23:32:03 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Wed, 03 Jul 2002 09:50:05 GMT
ETag: "8e2ba27722c21:850"
Content-Length: 3292
<html>
<head>
<title>青澀寶貝主題站－－SG fans的世界！！！</title>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<link rel="stylesheet" href="all.css" type="text/css">
.......
這是正常的訪問方法，但是如果我們胡亂輸入請求呢？看：
HTTP/1.1 400 Bad Request
Server: Microsoft-IIS/5.0
Date: Sat, 20 Jul 2002 23:37:59 GMT
Content-Type: text/html
Content-Length: 87
<html><head><title>Error</title></head><body>The parameter is incorrect. </body></html>
呵呵，HTTP 400 - 錯誤請求，其實就是HTTP語法錯誤，服務器老老實實給我們返回了。
可以得出結論：無論你輸入了什麼，服務器根據HTTP協議，總會返回信息
通常用得最多的DOS方法主要有SYN、Smurf、Land、TearDrop等，其中SYN的資料如下（抄來的資料~~呵呵）
假設一個用戶向服務器發送了SYN報文後突然死機或掉線，那麼服務器在發出SYN+ACK應答報文後是無法收到客戶端的ACK報文的（第三次握手無法完成），這種情況下服務器端一般會重試（再次發送SYN+ACK給客戶端）並等待一段時間後丟棄這個未完成的連接，這段時間的長度我們稱爲SYN Timeout，一般來說這個時間是分鐘的數量級（大約爲30秒-2分鐘）；一個用戶出現異常導致服務器的一個線程等待1分鐘並不是什麼很大的問題，但如果有一個惡意的攻擊者大量模擬這種情況，服務器端將爲了維護一個非常大的半連接列表而消耗非常多的資源----數以萬計的半連接，即使是簡單的保存並遍歷也會消耗非常多的CPU時間和內存，何況還要不斷對這個列表中的IP進行SYN+ACK的重試。實際上如果服務器的TCP/IP棧不夠強大，最後的結果往往是堆棧溢出崩潰---即使服務器端的系統足夠強大，服務器端也將忙於處理攻擊者僞造的TCP連接請求而無暇理睬客戶的正常請求（畢竟客戶端的正常請求比率非常之小），此時從正常客戶的角度看來，服務器失去響應，這種情況我們稱作：服務器端受到了SYN
Flood攻擊（SYN洪水攻擊）。
而Smurf、TearDrop等是利用ICMP報文來Flood和IP碎片攻擊的。
但是以上的DOS方法的目的無非都是讓服務器大量消耗資源和超時連接，那麼除了超時連接，能不能用“正常連接”的方法來產生拒絕服務攻擊呢？
再來看看19端口的定義：
字符產生器協議（Character Generator Protocol）
字符產生器服務器一個有用的調試工具。無論接收到的是什麼，它都返回特定的數據。
基於TCP的字符產生器服務
此服務可以是一個基於TCP的服務，TCP端口19是用於此服務的。一旦連接建立，服務器會傳送一個字符流。接收到的信息會被拋棄。字符流會在用戶請求下中止。用戶可能會非正常中止一個連接，因此此服務必須準備處理這種情況。傳輸的速度會由TCP流控制機制負責，用戶不必關心數據太快，而用戶來不及處理。
19端口在早期已經有人用來做Chargen攻擊了，即Chargen_Denial_of_Service，但是！他們用的方法是在兩臺Chargen服務器之間產生UDP連接，讓服務器處理過多信息而DOWN掉，那麼，幹掉一臺WEB服務器的條件就必須有2個：1.有Chargen服務 2.有HTTP服務
實際上，現在是無法找到這麼多同時開放兩個這兩個服務的服務器的。
看看開頭的HTTP協議特性，和Chargen比較一下，你發現了什麼？哈哈~~~沒錯！一個是無論接收到什麼報文都會迴應，一個是一旦連接建立就會發送報文，看看示意圖：
發送請求------------------------------------->
客戶端----------------------------------------------------------服務器
<-------------------------------------------迴應
如果把客戶端改爲Chargen，就是以下情況：
字符流--------------------------------------->
Chargen----------------------------------------------------------服務器
<-----------------------------------400 Bad Request
也就是說，這兩者會產生利害衝突，可以這樣比喻：兩個人吵架，你罵一句，他還一句，這就是循環過程，除非有一方停止或第三者干涉，否則這將是個Do...Loop循環！
搬到HTTP和Chargen來說，就是因爲這兩者的特性正好天生一對，那好，就從這裏下手：
攻擊者僞造源IP給N臺Chargen發送連接請求（Connect），如有必要還可以發送（Send）個“Fuck you”報文過去，Chargen接收到連接後就會返回每秒72字節的字符流（實際上根據網絡實際情況，這個速度更快）給服務器，HTTP協議處理這個報文時當然會識別爲400 Bad Request而返回一條錯誤說明給它，接下來的情況嘛………………自己發揮想像力，別問我。
我用自己的機器（640 kbps ADSL）+VB Winsock程序做測試，只用了3秒鐘，程序就因爲內存溢出而崩潰了（主要是TextBox的問題，它接受文本的最大範圍爲64KB），就是說，3秒鐘內Chargen就發送了大於64KB的字符流！如果用大於10臺的Chargen一起發起攻擊，其速度足以大量消耗服務器資源和帶寬
