Как получать HTTP-сообщения с помощью сокета

если проблема является узким местом с точки зрения ReadByte будучи слишком медленным, я предлагаю вам обернуть входной поток с StreamBuffer. Если проблема производительности, которую вы утверждаете, стоит дорого из-за небольших чтений, то это решит проблему для вас.

кроме того, вам не нужно это:

string line = Encoding.ASCII.GetString(lineBuffer.ToArray()); 

HTTP по дизайну требует, чтобы заголовок состоял только из символов ASCII. Вы действительно не хотите-или должны-превратить его в фактические строки .NET (которые Юникод.)

если вы хотите найти EOF заголовка HTTP, вы можете сделать это для хорошей производительности.

int k = 0;
while (k != 0x0d0a0d0a) 
{
    var ch = stream.ReadByte();
    k = (k << 8) | ch;
}

после строки \r\n\r\n это обнаружил k будет равна 0x0d0a0d0a

в большинстве (должны быть все) http-запросов должен быть заголовок content-length, который скажет вам, сколько байтов есть в теле запроса. Тогда это просто вопрос выделения соответствующего количества байтов и чтения этих байтов сразу.

хотя я склонен согласиться с mdma о попытке как можно больше избежать реализации собственного http-стека, один трюк, который вы могли бы рассмотреть,-это чтение из кусков потока среднего размера. Если вы делаете чтение и даете ему буфер, который больше, чем то, что доступно, он должен вернуть вам количество байтов, которые он прочитал. Это должно уменьшить количество системных вызовов и значительно ускорить вашу производительность. Вам все равно придется сканировать буферы, как и сейчас, хотя.

взглянуть на код другого клиента полезно (если не путать): http://src.chromium.org/viewvc/chrome/trunk/src/net/http/

в настоящее время я тоже делаю что-то подобное. Я нахожу лучший способ повысить эффективность клиента-использовать предоставленные функции асинхронных сокетов. Они довольно низкоуровневые и избавляются от напряженного ожидания и работы с потоками самостоятельно. Все они имеют Begin и End в названии метода. Но сначала я попробовал бы использовать блокировку, просто чтобы вы убрали семантику HTTP с пути. Тогда вы сможете работать над эффективностью. Помните: преждевременная оптимизация-это зло, поэтому заставьте ее работать, а затем оптимизируйте все!

кроме того: некоторые из вашей эффективности могут быть связаны с использованием ToArray(). Известно, что это немного дорого с точки зрения вычислений. Лучшим решением может быть сохранение промежуточных результатов в byte[] buffer и добавьте их в StringBuilder С правильным кодирование.

для данных gzipped или deflated, прочитайте все данные (имейте в виду, что вы можете не получить все данные при первом запросе. Следите за тем, сколько данных вы прочитали, и продолжайте добавлять в тот же буфер). Затем вы можете декодировать данные с помощью GZipStream(..., CompressionMode.Decompress).

Я бы сказал, что это не так сложно, как некоторые могут предполагать, вы просто должны быть немного авантюрным!

все ответы здесь о расширении сокета и / или TCPClient, похоже, упускают что - то действительно очевидное-что HttpWebRequest также является класс и поэтому может быть расширен.

вам не нужно писать свой собственный класс HTTP / socket. Вам просто нужно расширить HttpWebRequest с помощью пользовательского метода подключения. После подключения все данные являются стандартными HTTP и могут обрабатываться как обычно базовым классом.

public class SocksHttpWebRequest : HttpWebRequest

   public static Create( string url, string proxy_url ) {
   ... setup socks connection ...

   // call base HttpWebRequest class Create() with proxy url
   base.Create(proxy_url);
   }

рукопожатие носков не особенно сложный, поэтому, если у вас есть базовое понимание программирования сокетов, это не займет много времени, чтобы реализовать соединение. После этого HttpWebRequest может выполнять тяжелый подъем HTTP.

почему бы вам не прочитать до 2 новых строк, а затем просто захватить из строки? Производительность может быть хуже, но она все равно должна быть разумной:

Dim Headers As String = GetHeadersFromRawRequest(ResponseBinary)
   If Headers.IndexOf("Content-Encoding: gzip") > 0 Then

     Dim GzSream As New GZipStream(New MemoryStream(ResponseBinary, Headers.Length + (vbNewLine & vbNewLine).Length, ReadByteSize - Headers.Length), CompressionMode.Decompress)
ClearTextHtml = New StreamReader(GzSream).ReadToEnd()
End If                         

 Private Function GetHeadersFromRawRequest(ByVal request() As Byte) As String

        Dim Req As String = Text.Encoding.ASCII.GetString(request)
        Dim ContentPos As Integer = Req.IndexOf(vbNewLine & vbNewLine)

        If ContentPos = -1 Then Return String.Empty

        Return Req.Substring(0, ContentPos)
    End Function

Вы можете посмотреть на TcpClient класс System.Net, Это оболочка для сокета, которая упрощает основные операции.

оттуда вам придется прочитать протокол HTTP. Также будьте готовы сделать некоторые операции zip. Http 1.1 поддерживает GZip его содержимого и частичных блоков. Вам придется научиться разбирать их вручную.

основной Http 1.0 прост, протокол хорошо документирован онлайн, наше дружелюбное соседство Google может помочь вам с этим.

Я бы создал прокси-сервер SOCKS, который может туннелировать HTTP, а затем принимать запросы от HttpWebRequest и пересылать их. Я думаю, что это было бы намного проще, чем воссоздавать все, что делает HttpWebRequest. Вы можете начать с Privoxy, или просто свернуть свой собственный. Протокол прост и документирован здесь:

http://en.wikipedia.org/wiki/SOCKS

и на RFC, на которые они ссылаются.

Вы упомянули, что вы должны иметь много разных прокси-серверов-вы можете настроить локальный порт для каждого из них.