사업자가 HTTP 납치 (DNS 납치 아님) 를 통해 광고를 푸시하는 것은 낯설지 않다. 해결책은 대부분 부가 가치 업무 부서에 불만을 제기하고 공신부에 불만을 제기하는 것이다. 하지만 이 방법은 시간이 많이 걸리고, 상황을 이해하지 못하는 불만 대상들이 많아, 묻지 않는 상황에 대한 답변을 하게 된다. (윌리엄 셰익스피어, 햄릿, 지혜명언) 때로는 화가 났을 뿐만 아니라 문제를 완전히 해결할 수 없는 경우도 드물거나, 일정 기간 후에 문제가 재발하는 경우도 적지 않다.

최근 몇 년 동안 운영자의 HTTP 납치는 수렴하지 않았을뿐만 아니라 점점 더 심해져서 HTTP 납치를 통한 암호 차단과 같은 새로운 트릭을 만들었습니다. 예를 들어, 다운로드 된 소프트웨어가 대체됩니다. 예를 들어, 리베이트를 위해 납치하는 것입니다.

이 기사에서는 HTTP 납치를 방지하는 기술적 수단에 대해 설명합니다. 대부분의 경우 광고 푸시 문제뿐만 아니라 비밀번호 차단 및 소프트웨어 교체 다운로드 문제도 해결할 수 있습니다. 최종 효과는 운영자가 하이재킹 후 브라우저 플러그인을 통해 광고를 필터링하는 대신 HTTP 하이재킹을 중지하는 것입니다. 이 방법의 장점은 광고 필터링을 위해 브라우저 플러그인을 설치할 필요가 없고, HTTP 에이전트나 VPN 과 같은 추가 서버가 필요하지 않으며, 다운로드한 소프트웨어가 리베이트 교체로 납치되는 것을 방지하거나 비밀번호 유출을 어느 정도 막을 수 있다는 것입니다.

이러한 기술적 수단의 작동 원리를 설명하기 위해서는 사업자가 대부분의 경우 HTTP 하이재킹 원리를 설명해야 합니다.

사용자의 브라우저가 방문한 웹 서버에 연결하고 HTTP 요청을 전송하면 통신업체의 라우터가 먼저 이 HTTP 요청을 수신한 다음 통신업체 라우터의 우회 장치가 TCP 연결을 HTTP 프로토콜로 표시한 다음 웹 서버가 데이터를 반환하기 전에 HTTP 프로토콜을 전송하는 302 코드를 통해 다운로드 소프트웨어를 납치할 수 있습니다. 브라우저가 302 코드를 받으면 잘못된 소프트웨어 다운로드 주소로 이동하여 소프트웨어를 다운로드하면 웹 서버의 실제 데이터가 삭제됩니다. 또는 이 TCP 연결을 HTTP 프로토콜로 표시한 후 우회 장치는 수정된 HTML 코드를 직접 반환하여 브라우저에 운영자의 광고를 삽입한 다음 웹 서버의 실제 데이터가 도착하면 폐기됩니다.

앞서 살펴본 바와 같이 HTTP 납치가 필요한 경우 먼저 HTTP 프로토콜인 경우 납치가 필요하며 그렇지 않으면 납치가 필요하지 않습니다. 그렇다면 우회 장치에 의해 HTTP 프로토콜로 표시된 것을 피할 수 있는 방법이 있습니까? 대상 사이트는 타사 서버가 없어도 원본 HTTP 요청을 받을 수 있습니까? 대답은' 예' 입니다.

우회 장치에서 HTTP 프로토콜을 감지하는 모듈은 일반적으로 간단합니다. 일반적으로 TCP 연결이 설정된 후 첫 번째 패키지만 감지하고 전체 HTTP 프로토콜인 경우 태그를 지정합니다. 완전한 HTTP 프로토콜이 아닌 경우 충분한 납치 정보를 얻을 수 없기 때문에 HTTP 프로토콜로 표시되지 않습니다 (우리의 방화 만리장성은 그렇지 않습니다. 후속 패킷이 검사되므로 이 방법은 유효하지 않습니다). 이 상황을 이해하면 하이재킹을 방지하는 방법은 간단합니다. HTTP 요청을 여러 패킷으로 분할한 다음 운영자를 속여 HTTP 하이재킹을 방지합니다. 그러나 대상 사이트 운영 체제의 TCP/IP 스택은 비교적 완벽해서 수신된 HTTP 요청은 여전히 완전하며 웹 브라우징에 영향을 주지 않습니다.

브라우저에서 보낸 HTTP 요청을 여러 패키지로 분할하려면 어떻게 해야 합니까? 로컬에서 프록시 서버를 설정하고, 프록시 서버에서 브라우저의 HTTP 요청을 압축 해제할 수 있으며, 브라우저는 로컬 프록시 서버를 설정할 수 있습니다. 여기서 테스트한 결과, 기본 설정은 3 대 사업자 (차이나 텔레콤, 차이나 유니콤, 차이나 모바일) 의 HTTP 납치를 억제하는 데 좋은 역할을 했습니다.