2013-09-02 2 views
0

지난 2 일 동안 일부 코드를 조합 한 HTTP 1.1/1.0 프록시를 지원하는 SSL을 작성했습니다. HTTPWebResponse/HTTPWebRequest 클래스를 사용하여 서버에서 데이터를 가져 왔습니다. 서버에서 데이터를 중계하는 동안 헤더를 먼저 브라우저로 보내고 서버에서 응답 스트림을 보낸다. 응답이 청크 일 때 스트림 리더를 사용하여 HTTPWebresponse.GetResponseStream()을 사용하여 읽은 다음 브라우저로 전달하면 브라우저가 페이지를로드하지 못하는 것으로 나타났습니다. 약간의 시간을 보낸 후에 GetResponseStream()이 이미 dechunked 인 것처럼 보임으로써 브라우저가 구문 분석에 실패하여 (청크 된 응답 헤더가 이미 브라우저로 보내 졌기 때문에) 혼란 스럽습니다. 청크 헤더를 제거한 다음 청크없이 응답 스트림을 함께 보냄으로써 해결 방법을 만들었습니다.프록시에서 릴레이 청크 응답

괜찮 았어.하지만 피들러 코어 (로열티없는 프록시 라이브러리)가 어쨌든 청크 데이터를 중계하지 않고 중계했음을 알았다. 닷넷으로 작성되었으므로 중계 할 방법이 있어야한다고 생각한다. 청크 하나씩.

그래서 내 질문은 제대로 프록시에서 스트림을 사용하여 chucked 응답을 릴레이하는 방법입니다? 또한 내 프록시가 로컬 시스템을 대상으로하는 경우 청크없이 데이터를 브라우저에 함께 보내면 성능이 떨어지게됩니다 (프록시는 요청시 서버에서 청킹을 사용하고 반대에서는 역으로 사용함).

답변

0

나는 실제로 응답 헤더에서 버퍼로 읽을 때마다 데이터를 다시 청크하기로 결정했습니다 (응답 헤더가 청크 응답을 나타내는 경우에만). 재 청킹에서의 성능 저하는 무시할 만하다고 생각합니다. 해결 방법에서 언급 한대로 모든 청크가 읽히기를 기다렸다가 프록시에 사용할 수있는 메모리를 날려 버릴 가능성이 있습니다.

0

FiddlerCore는 TCP/IP 소켓 바로 위에 쓰여진 HTTP/1.1 프로토콜의 완전한 구현입니다.

이와 같이 상위 수준 WebRequest 클래스의 고유 한 제한 사항을 겪지는 않습니다 (프로토콜을 완전히 구현해야한다는 비용이 들기 때문에).

+0

오케이 Eric. 사실 내 프록시는 피들러 코어와 거의 동일한 성능으로 작동합니다. 나는 궁금해하는 구현 문제를 근절한다. – justcoding124

+0

광범위한 테스트를하지 않았으며 피들러보다 더 나은 것을 주장하지 않았습니다. :-) – justcoding124

+1

FiddlerCore의 핵심 속성은 성능이 아닙니다 (괜찮습니다) - 대신 * 호환성 *입니다. 브라우저와 서버의 모든 단점을 지원하는 프록시를 구현하는 것은 상당히 어렵습니다. – EricLaw

관련 문제