TIL
오브젝트 독후감
HTTP 트랜잭션
초간단 프록시
독후감(~6장)
이틀에 걸쳐서 <오브젝트>의 2장~6장을 훑어보았다. 음... 무언가 줄글 내용은 많았는데 (200페이지 정도) 말하고자 하는 핵심 내용은 줄이자면 되게 컴팩트하게 줄일 수 있을 것 같다.
아직 유연한 설계가 필요한 실무에 들어가 본 적도 없고, 내가 짠 코드에 수정 요구사항이 들어온 경험도.. 아니 있지만 되게 사소한거라 "객체지향적이다"라는 말이 항상 뜬구름을 잡는 것 같다고 생각했는데,(사실 지금도 와닿는건 아님) 책에서 수차례 강조한 부분이 있으니까 어느정도 아.. 이런 거구나. 싶은 느낌이 든다.
<오브젝트>의 전반부에서 나온 내용을 간략하게 정리해봤다.
- 프로그램을 "데이터를 가진 클래스의 집합"이 아닌, "책임을 가진 자율적 객체들의 협력"으로 보자.
- 책임을 가진 추상화된 존재에게 메세지 패싱을 하자.
- 협력의 맥락에서 사용 가능한, "무엇을 하는지" 나타내는 인터페이스만을 제공하자. 이 인터페이스는 직전의 메세지 패싱에 이용된다.
- 추상 인터페이스에 의존하여 클라이언트 객체는 메세지를 던지지만 메세지를 받는 서버 객체쪽에서 실행시에 실제로 실행할 메소드를 결정한다. 이 때 클라이언트는 서버 객체에서 어떤 메소드가 실행될지 몰라도 된다.
- 객체가 가진 데이터는 객체의 책임을 수행하기 위해 필요한 것들이어야 한다.
- 코드의 응집도를 높이고, 결합도를 낮춰 변화에 유연하고 읽기 쉬운 코드를 작성해야 한다. 이를 위해서 하나의 객체는 하나의 책임만을 수행해야 한다.
개념 위주로 다뤘던 전반부의 대략적인 내용은 위 항목 정도로 정리될 수 있을 것 같다. 실제 코드 위주로 많이 설명했는데(영화 계산 로직이라든가..) 더 도움이 됐던듯? 초반엔 멍때리고 읽다가 직접 코드 따라치면서 설계를 따라가봤는데 생각보다 복잡하고 어려웠다.
추가로, 캡상추다를 배울 때 개념적으로 그냥 정보은닉이다-하고 말았던 캡슐화, 그리고 모델링이다-하고 말았던 추상화가 설계와 객체지향 측면에선 가장 중요한 개념이었다는 것이 개인적으로 좀 놀라웠다. 물론 다형성과 상속도 중요하긴 한데 이 둘은 뭔가 캡슐 및 추상화를 위한 조금더 concrete한.. 기능적인.. 개념이라 더 와닿고 설명하기도 쉽기 때문에
사실 완전한 설계 "법칙"은 존재하지 않고, 대부분은 필요할 때 적당한 트레이드오프를 통해 기능을 구현한다... 까지 알면 될듯?
HTTP 트랜잭션
HTTP는 TCP/IP 프로토콜을 이용한다. 이전에 여러번 글로 정리했지만 다시 한 번 간단하게 줄글로 설명해보면!
URL은 스킴, 호스트명, 포트번호, path, 쿼리 파라미터, 프라그먼트로 이루어져있다.
일단 브라우저에 URL을 치면
- https 프로토콜로 GET 요청을
- www.google.com 이라는 컴퓨터의
- 443번 포트로 날릴 것이다
- 경로는 /search
- 파라미터는 q:hello, hi:ko
로 구성된 HTTP 요청 메세지가 생성된다. 요청 라인 GET /search HTTP/1.1, 기타 헤더, 아마 본문은 빈 채로 메세지가 뿅! 나오는 것이다.
이 4계층 메세지는 3계층으로 내려간다. TCP 프로토콜은 신뢰성있는 연결을 보장하기 위해 해당 프로토콜에서 사용하기 위한 정보가 담긴 TCP 헤더를 추가해 HTTP 메세지를 감싼다. 송/수신지의 포트번호, 각종 컨트롤 비트, 시퀀스 넘버 등등이 그것이다. TCP 통신을 위한 3-way handshake, 혼잡 및 흐름 제어.. 등등의 과정이 여기서 진행된다. TCP 지연이 발생하는 지점이기도 하다.
3계층 메세지는 2계층으로 내려간다. IP 프로토콜은 IP주소를 이용해 메세지를 목적지 컴퓨터까지 배달하는 역할을 한다. 그를 위해 필요한 정보가 담긴 패킷 헤더(송/수신지의 IP주소)를 추가하여 패킷 단위로 1계층에 내려보낸다.
1계층은 MAC주소 기반 통신을 위해 패킷을 프레이밍화하여 물리 통신을 진행한다. ARP가 사용되고 어쩌구 하는 구간이다.
서버에 도착한 HTTP 메세지는 WS에 의해 정적 응답 메세지가 되어 되돌아오거나, WAS에 의해 일정한 로직이 수행된 동적 응답 메세지가 되어 돌아온다. 응답 메세지 body에는 HTML을 포함해 이미지, 음성, 영상, 파일 등등 모두가 올 수 있다.
이러한 HTTP 커넥션은 네트워크 혼잡, 하드웨어 문제 등 여러 이유로 지연 문제를 겪는다. 이를 조금이라도 해결할 수 있는 방법이 없을까?
1) 병렬 커넥션
여러 개의 커넥션을 맺어 HTTP 메세지를 병렬적으로 교환한다. 클라이언트 대역폭이 허용하는 한, 일반적으로 더 빠르다. 그러나 하드웨어 리소스의 한계와 커넥션 생성시의 부하 때문에 병렬 커넥션을 일정 개수 이상으로 늘릴 순 없고, 일반적으론 4~6개 사이를 유지한다고 한다.
2) 지속 커넥션
한 번 생성된 TCP 커넥션을 여러 번의 트랜잭션동안 재사용하는 방법이다. TCP 연결은 비용이 많이 들고, 한 번 연결된 서버와 클라이언트는 일반적으로 여러 번의 트랜잭션을 수행하므로 이 방법은 합리적이다.
HTTP/1.0+ Keep-alive
요청 헤더에 Connection:Keep-Alive를 추가하는 방법. 서버가 이를 이해하면 응답 메세지의 헤더에도 같은 항목을 추가하며, 이 헤더가 각 응답-요청 메세지쌍에 있는 동안 서버와 클라이언트는 지속 커넥션 안에서 트랜잭션을 수행한다.
멍청한 프록시문제가 있는데, Connection을 이해하지 못하는 헤더가 이를 삭제하지 않고 서버와 클라이언트 모두에게 그대로 전달해버리면, 서버와 클라이언트는 TCP 연결을 끊지 않는데 프록시만 끊기길 기다리며 아무 일도 하지 않는 문제가 발생해버린다.
HTTP/1.1 지속 커넥션
HTTP/1.1에선 별도의 설정(Connection:close)이 없으면 지속 커넥션은 기본적으로 활성화되어있다.
또한 파이프라인 커넥션이라는 것도 있는데, 하나의 커넥션 안에서 여러 개의 요청을 순차적으로 보내고 그 순서에 맞춰 응답을 받는다. 이 때 연속적으로 보내는 요청은 응답이 도착하기 전에도 전송 가능하다.
이 때 주의해야 할 것이 있는데, 멱등하지 않은 요청은 파이프라인 커넥션에 사용하면 안된다. 연속적으로 보낸 요청에 대해 서버 측에서 요청 처리가 되었는지 확인하지 못하기 때문이다.
초간단 프록시
프록시는 간단히 말해 클라이언트와 서버 사이의 "중개인"이다. 프록시는 클라이언트와 서버 중간에 위치하면서 클라이언트의 모든 HTTP 요청을 받아 서버에 전달한다. (대개 요청을 수정한 뒤에)
클라이언트의 입장에서 보면 서버와의 트랜잭션을 대신 수행해주는 대리자 정도의 위치인 것이다.
HTTP 프록시 서버는 클라이언트 입장에선 서버고, 서버 입장에선 클라이언트다. 응답 메세지와 요청 메세지를 모두 전달하기 때문이다.
# 왜 사용하죠
일단 "필터링"을 위해 사용한다. 학교 컴퓨터실 서버나, 아이들이 사용하는 컴퓨터에 특정 IP로부터의 콘텐츠를 차단할 수 있다. 사용자 컴퓨터에 도착하기 전에 프록시 서버 단에서 IP를 보고 요청이나 응답을 차단할 수 있다.
"보안"을 위해 사용될 수 있다. 사내 서버 앞에 프록시를 두고, 특정 경로에 대한 요청을 차단할 수 있다. 혹은 네트워크 점검용 훅을 제공하는 프록시를 사용해 서버에 들어오고 나가는 요청을 감시하고 필터링할 수 있다.
캐시 서버로서도 동작할 수 있다. 사용자들이 자주 찾는 정적 컨텐츠를 중간 프록시에 업로드하면 각각의 요청에 원서버가 응답할 필요가 없으므로 더 빠른 컨텐츠 제공이 가능하다.
사용자 익명화도 가능하다. 서버에 요청을 보내는 대리인으로 프록시를 이용하면, 프록시가 보내는 패킷의 송신 IP를 익명으로 설정하여 요청 컴퓨터를 감출 수 있는 것이다.
반대로 리버스 프록시로 작동하여, 웹 서버 바로 앞에 놓여 캐시 서버 비슷한 동작을 취하거나, 트래픽에 대해 적절한 로드밸런싱을 하거나, 서버의 보안을 지킬 수 있다.
이외에도 사용할 이요는 4천만가지 정도 되는데 이만 줄임!
REFERENCE
<오브젝트> 3,4,5,6장
HTTP 완벽 가이드 5,6장
