📚독서 스터디

독서 스터디 6주차! 이번장은 뭔가.. 이전장들에 비해서 별로 재미 없었어요!
5장까지 책 내용을 적으면서 생각했던건데, 너무 길게 나열하는 느낌이 강해서... 더 간략하게 정리를 해 볼까 하는데.. 계속 고민 해야겠습니다.
아무튼.. 6주차도 어김없이 읽은 내용을 정리하고 문제를 만들어 가야합니다!

📖프락시

클리어인터의 입장에서 트랜잭션을 수행하는 중개인이다.

웹 프락시가 없다면?

클라이언트는 HTTP 서버와 직접 이야기한다.

웹 프락시가 있다면?

클라이언트는 HTTP 서버와 직접 이야기하는 대신, 자신의 입장에서 서버와 대화해주는 프락시와 이야기한다.

📝프락시 vs 게이트웨이

프락시는 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결
게이트웨이는 서로 다른 프로토콜을 사용하는 둘 이상을 연결

사실...🤥

둘의 차이는 모호하다! 브라우저와 서버는 다른 버전의 HTTP를 구현하기 때문에, 프락시는 때때로 약간의 프로토콜 변환을 하기도 한다.

🤔왜 사용하는가?

실용적으고 유용한 것이라면 무슨 일이든 하는 프락시! 보안을 개선하고, 성능을 높여주며, 비용을 절약한다.

• 성인 콘텐츠를 차단하는 필터링
• 웹 서버들에 대한 접근을 제어
• 조직안에 들어오거나 나가는 응용 레벨 프로토콜의 흐름을 네트워크의 한 지점에서 통제하는 보안기능
• 자주 들르는 문서의 로컬 사본을 관리하고 해당 문서에 대한 요청이 오면 빠르게 제공하는 캐시
• 웹 서버 요청을 받지만 웹 서버와는 달리 요청 받은 콘텐츠의 위치를 찾아내기 위해 다른 서버와 커뮤니케이션을 시작하는 대리 또는 리버스(서버 가속기)
• 트래픽 조건과 콘텐츠의 종류에 따라 요청을 특정 웹 서버로 유도하는 콘텐츠 라우터
• 콘텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정할 수 있다. GIF -> JPG, 색 강도 조절, 텍스트 파일 압축, 텍스트 변환등의 트랜스코딩
• HTTP 메시지에서 신원을 식별할 수 있는 특성들을 적극적으로 제거하는 익명화

🥓프락시 계층

프락시 계층에서, 메시지는 최종적으로 원 서버에 도착할 때까지 프락시와 프락시를 거쳐 이동한다.
프락시 서버들은 부모와 자식의 관계를 갖고, 아래와 같은 흐름으로 언제나 메시지가 흐른다.

클라이언트 <=> 프락시1 <=> 프락시2 <=> 프락시3 <=> 원 서버

🤸‍♂️그.렇.지.만! (역시나 항상 그런건 아닌가보다...)

계층이 반드시 정적이지는 않다. 동적으로 부모를 선택할 수 있는데 다음과 같은 경우가 그 예이다.

• 부모들의 작업략 수준에 근거하여 부모 프락시를 고르는 부하 균형
• 원 서버의 지역을 담당하는 부모를 선택하는 지리적 인접성에 근거한 라우팅
• URI에 근거하여 다른 부모나 원 서버로 라우팅 할 수 있는 프로토콜/타입 라우팅
• 웹서비스 운영자가 빠른 서비스를 위해 추가금을 지불했다면, 그들의 URI를 대형 캐시나 성능 개선을 위한 압축 엔진으로 라우팅 해 주는 유료 서비스 가입자를 위한 라우팅

🧐클라이언트는 어떻게 프락시를 찾는거야?

1. 클라이언트를 수정한다!

많은 웹 브라우저들은 수동 혹은 자동 프락시 설정을 지원한다.

2. 네트워크를 수정한다!

HTTP 트래픽을 지켜보고 가로채어 클라이언트 모르게 트래픽을 프락시로 보내는 스위칭 장치와 라우팅 장치를 필요로 한다. 인터셉트 프락시

3. DNS 이름공간 수정!

웹 서버 앞에 위치하는 대리 프락시는 웹 서버의 이름과 IP 주소를 자신이 직접 사용한다.

4. 웹 서버를 수정!

HTTP 리다이렉션 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 프락시로 리다이렉트 하도록 설정할 수 있다.

프락시 요청의 미묘한 특징❓

1. 프락시 URI !== 서버 URI

🤸‍♀️기존에는?

클라이언트는 단일한 서버와 직접 대화!

🤔왜?

단일 서버는 자신의 호스트 명과 포트번호를 알고 있으므로, 클라이언트는 불필요한 정보 발송을 피하기 위해 스킴과 호스트가 없는 부분 URI만 보냈다.

🤸‍♂️ 프락시가 부상한 이후에는?

프락시는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그 서버의 이름을 알 필요가 있다. 프락시 기반 게이트웨이는 FTP 리소스나 그 외의 스킴과 연결하기 위해 URI의 스킴을 알 필요가 있었다. 그렇기에 부분 URI가 문제가 된 것!

🙆‍♂️어떻게 해결해?

우리는 서버로는 부분 URI를, 프락시로는 완전한 URI를 보낼 필요가 있다.

• 클라이언트가 프락시를 사용하지 않도록 설정되어 있다면, 부분 URI를 보낸다.
• 클라이언트가 프락시를 사용하도록 설정되어 있다면, 완전한 URI를 보낸다.

2. 이건 가상 호스팅에서도 일어나는 문제였어!

요청이 부분 URI인 /index.html로 오면, 가상으로 호스팅 되는 웹 서버는 그 요청이 접근하고자 하는 웹 사이트의 호스트 명을 알 필요가 있다.

✨가상 호스팅은 이렇게 했어

가상으로 호스팅 되는 웹 서버는 호스트와 포트에 대한 정보가 담겨 있는 Host 헤더를 요구한다.

3. 인터셉트(대리) 프락시는 부분 URI

클라이언트는 자신이 프락시와 대화하고 있음을 항상 알고 있지 않다! 몇몇 프락시는 클라이언트에게는 보이지 않을 수 있기 때문이다!

• 대리 프락시는 원 서버의 호스트 명과 아이피 주소를 사용해 원 서버를 대신하는 프락시 서버다.
• 네트워크 흐름에서 클라이언트에서 서버로 가는 트래픽을 가로채 캐시된 응답을 돌려주는 등의 일을 하기에, 부분 URI를 얻게 된다.

4. 전송 중 URI 변경❓

이 부분은 정말 조심해야 한다! 아주 사소하고 무해해 보이는 URI 변경이라도 다운스트림 서버와 상호운용성 문제를 야기할 수 있다. 프락시 서버는 가능한 관대해야 하며, 특히 인터셉트 프락시가 URI를 전달할 때 절대 경로를 고쳐 쓰는 것을 금지한다. 오직 빈 경로를 '/'로 교체하는 것만이 유일한 예외이다.

5. URI 클라이언트 자동확장과 호스트 명 분석

브라우저는 요청 URI를 상황에 따라 다르게 분석한다.

• 프락시가 없다면! URI에 대응하는 IP주소를 찾는다.
• 호스트명이 발견되면 그에 대응하는 IP 주소들을 연결에 성공할 때까지 시도해본다.

❌호스트 명까지 발견을 못했으면?

호스트 명의 짧은 약어를 타이핑한 것으로 보고 자동화된 호스트 명의 확장을 제공한다.

• www.접두사를 붙이고, .com접미사를 붙인다. ex) naver만 타이핑 해도 자동 확장한다!
• 해석 불가능한 URI를 서드파티 사이트로 넘기기도 하며, 오타 교정을 시도하고 사용자가 의도했을 URI를 제시한다.
• 대부분 DNS는 사용자가 호스트 명의 앞부분만 입력하면 자동으로 도멘인을 검색하도록 설정되어 있다.

⚡메시지 추적

이제 클라이언트에서 서버로 흘러가는 요청이 둘 이상의 프락시를 지나는 일은 흔한 일이 되었다. 이에 따라 프락시를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다.

Via 헤더

메시지가 프락시나 게이트웨이를 지날때마다 해당 정보가 Via목록의 끝에 반드시 추가되어야 한다.
메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다.

TRACE 메서드

HTTP/1.1의 TRACE 메서드는 요청 메시지를 프락시의 연쇄를 따라가면서 어떤 프락시를 지나가고 어떻게 각 프락시가 요청 메시지를 수정하는지 관찰/추적할 수 있도록 해준다.

✨프락시 상호운용성

클라이언트, 서버, 프락시는 HTTP 명세의 여러 버전에 대해 여러 벤더에 의해 만들어진다. 그 종류와 특성, 버그가 가지각색이라는 뜻이다...!

1. 지원하지 않는 헤더와 메서드를 다루자🙅‍♂️

프락시 서버가 넘어오는 헤더 필드들을 모두 이해할 수는 없다. 그렇다면?

• 이해할 수 없는 헤더 필드는 반드시 그대로 전달한다.
• 같은 이름의 헤더 필드가 여러 개 있다면 그들의 상대적인 순서를 반드시 유지한다.
• 어떤 메서드와 친숙하지 않다면, 가능한 한 그 메시지를 다음 홉으로 전달하려 시도해야 한다.

2. OPTIONS

서버의 특정 리소스가 어떤 기능을 지원하는지(메서드) 클라이언트가 알아볼 수 있게 해준다.
OPTIONS * HTTP/1.1 : 서버 전체의 능력에 대해 묻는다.

3. Allow 헤더

지원되는 메서드들이나 서버가 지원하는 모든 메서드(요청 URI가 *인 경우)를 열거한다.
프락시는 Allow 헤더 필드를 수정할 수 없다. 클라이언트는 원 서버와 대화하는 다른 경로를 갖고 있을 수도 있기 때문에!

마무리

처음 읽을 때는 재미 없었는데! 정리하며 다시 읽어보니 또 단어가 익숙해 졌다고 재밌게 정리했습니다.
너무 장황한 설명이나, 중요치 않다고 생각되는(지극히 개인적인) 키워드 몇개는 쪼끔 빠졌는데.. 잘 판단이 안서니 역시 정리를 한다는게 쉽지 않네요.
프락시 관련된 포스팅을 보면 항상 이게 무슨 소리야? 했는데 프락시라는 친구와 조금이라도 알게 된 거 같으니 앞으로는 좀 더 알아들을 수 있겠죠!