8바이트를 읽은 뒤 SOCKS4 터널을 넘겨라
SOCKS4 응답의 고정된 경계를 파싱해 목적지의 인사말을 삼키거나 존재하지 않는 바이트를 기다리는 일을 피하세요.
SOCKS4 연결 요청은 성공하지만 애플리케이션은 서버의 첫 인사말을 결코 보지 못합니다. 살펴볼 곳 중 하나는 커넥터의 첫 읽기입니다. 16바이트 읽기는 8바이트 SOCKS4 응답에 너무 큽니다.
| 응답 필드 | 바이트 |
|---|---|
| 응답 버전 필드 | 1 |
| 결과 코드 | 1 |
| 포트 필드 | 2 |
| 주소 필드 | 4 |
결과 코드 0x5a 는 요청이 승인되었음을 나타냅니다. SOCKS4a는 요청이 호스트 이름을 실어 나르는 방식을 바꾸지만, 응답을 16바이트로 만들지는 않습니다.
응답 뒤에 같은 TCP 스트림은 목적지 프로토콜을 실어 나릅니다. 메일 서버는 인사말을 즉시 보낼 수 있습니다. 따라서 사용 가능한 16바이트를 소비하는 읽기는 프록시 응답 전체와 그 인사말의 첫 8바이트까지 가져갈 수 있습니다. 아직 아무것도 뒤따르지 않는다면, 너무 큰 블로킹 읽기는 대신 불필요한 대기를 더합니다.
정확한 길이는 파서의 책임
한 번에 8바이트를 요청하는 것은 8바이트가 도착했다는 충분한 증거가 아닙니다. 스트림 읽기는 더 적게 반환할 수 있습니다. 기한 안에서 응답 길이를 정확히 모으고, 닫히거나 실패한 스트림에서는 멈추고, 응답을 검사하고, 뒤따르는 바이트는 애플리케이션에 남겨 두세요.
커넥터가 더 큰 버퍼 읽기를 쓴다면 경계 이후의 모든 것을 보존해 다음 소비자에게 넘기세요. 남은 부분을 버리는 것은 읽기 크기만 다른 같은 데이터 손실입니다.
SOCKS5는 자체 파서가 필요합니다. 응답 주소의 길이는 주소 유형에 따라 다를 수 있습니다. 모든 프록시 읽기를 고정 8바이트 읽기로 바꾸면 한 프로토콜을 고치면서 다른 프로토콜을 깨뜨립니다.