목표 SSO(Single sign-on)가 무엇인지 이해한다. SSO와 OAuth, SAML의 관계를 이해한다. SSO란 SSO: 하나의 자격 증명으로 여러 애플리케이션과 웹사이트에 인증할 수 있는 인증 방법이다. 예시: 구글 로그인으로 Gmail, YouTube 등 인증 가능 일반적인 SSO 흐름 사용자가 접근하려는 애플리케이션 또는 웹사이트(SP)를 접속한다. SP는 사용자 인증 요청의 일부로 사용자에 대한 일부 정보(이메일 등)가 포함된 토큰을 SSO 시스템과 같은 IdP에 보낸다. IdP는 사용자가 이미 인증되었는지 확인하며, 인증된 경우 사용자에게 SP 애플리케이션에 대한 액세스 권한을 부여하고 5단계로 건너뛴다....
배경 어떤 구성원의 프로필 사진을 조회할 수 있는 API가 있다. 해당 API는 구성원의 프로필 사진 URL을 구해서, 302 응답을 내려준다. (Location 헤더에 프로필 사진 URL) 해당 API는 Authorization 헤더를 참조해 인증/인가 작업을 거친다. 프로필 사진 URL에 접근할 때도 Authorization 헤더가 필요하다. 프로필 사진 조회 API와 프로필 사진 URL의 호스트는 다르다. API를 호출해보니 리다이렉트는 되었지만 프로필 사진 URL 조회 시에 인증 실패가 발생한다. 원인 Postman이나 curl 명령어 등 대부분의 HTTP 클라이언트에서는 다른 호스트로 리다이렉트 될 때 Authorization 헤더는 유지하지 않고 요청을 보낸다....
목표 GSLB가 무엇인지 이해한다. GSLB란? Global Server Load Balancing 전 세계에 걸쳐 분산되어 있는 서버들을 대상으로 로드밸런싱하는 기법 GSLB는 분산되어 있는 서버를 아래와 같은 기준으로 선택해 로드밸런싱 한다. 네트워크 지연 시간 지리적 근접성 서버 가용성 네트워크 상태 서버 부하 etc CDN도 GSLB 기술을 사용한 것이라고 볼 수 있다. GSLB로 얻을 수 있는 이점 네트워크 지연 시간 감소: 지역적으로 가까운 서버를 선택하여 지연 시간을 줄일 수 있다. 안정성 및 가용성 증가: 로드 밸런서가 서버들의 상태를 모니터링하고 있어, 일부 서버가 중단되 었으면 다른 서버로 우회가 된다....
도메인 네임: 넓은 의미로는 네트워크 상에서 컴퓨터를 식별하는 호스트명을 가리키며, 좁은 의미에서는 도메인 레지스트리에게서 등록된 이름을 의미한다. 호스트 네임: 네트워크에 연결된 장치들에게 부여되는 각각의 고유한 이름입니다. 우리가 도메인 주소를 생성하고 나면 서비스를 구분하기 위해 별도의 서브 도메인을 사용하기도 합니다. https://velog.io/@minjae-mj/호스트-네임과-도메인-네임
두 가지 방법이 나왔었다. URI 경로: /rooms/pages/1 URI 쿼리: /rooms?page=1 페이지를 리소스로 취급하면 리소스간의 고유한 계층을 유지하기 힘들다는 단점이 있다. 예를들어 1번방으로 요청하려면 rooms/1 이라고 표현하고 싶은데 pages라는 리소스 때문에 불가능해진다. 따라서 페이지는 rooms라는 자원을 필터링하기 위한 하나의 표현이다. 따라서 URI 쿼리 방식을 선택했다. 참고 자료 https://www.baeldung.com/rest-api-pagination-in-spring
이런 고민을 한 이유: HTTP의 한계 무상태성: 클라이언트의 상태를 기억하지 않기 때문에 클라이언트에게 갱신된 정보를 알려줄 수 없다. 비연결성: 1개의 리퀘스트로 부터 응답을 하면 연결이 끊어진다. Polling: 주기적으로 클라이언트가 request를 보내 새로운 정보를 갱신하는 방법 장점 구현이 단순하다. 단점 주기적으로 HTTP 연결을 맺고 끊는게 상당한 클라이언트와 서버 측에서 모두 큰 부담이 된다. 이를 어느 정도 해결하기 위해 전송하는 데이터 양을 줄이기 위해 ajax를 사용한다. Long Polling(HTTP/1.1): 클라이언트와 서버가 계속 연결을 맺고 끊는 것을 줄이기 위해서 만든 방법....
소켓 연결을 유지하기 때문에 양방향 통신이 가능하다. 즉, 웹에서 사용하는 소켓이라 할 수 있다. 웹소켓과 HTTP 프로토콜 모두 OSI 모델에서 제7계층인 Application layer에 해당하며 제4계층인 TCP에 의존한다. TCP 소켓에서는 바이트 스트림을 사용하지만 웹 소켓에서는 UTF-8 포맷의 메시지 스트림만 허용한다. 웹소켓 통신 과정 WebSocket Handshake 클라이언트 핸드쉐이크 요청 GET /chat HTTP/1.1 Host: example.com:8000 Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 Upgrade: 웹소켓 프로토콜로 프로토콜을 변경한다는 요청 Sec-WebSocket-Key: 핸드쉐이크에 필요한 키 Connection: 프록시에 더 이상 전송하지 않는 헤더 필드를 지정하는 헤더다....
301 Moved Permanently: 리퀘스트된 리소스에는 새로운 URI로 영구히 이동되었기 떄문에 이후로는 그 리소를 참조하는 URI를 사용해야된다는 뜻이다. 새로운 URI는 Location 헤더 필드에 명시되어 있다. 브라우저는 이 페이지로 리디렉션되고 리소스에 대한 링크를 업데이트 한다. 302 Found: 리퀘스트된 리소스가 새로운 URI로 일시적으로 이동했다는 뜻이다. 브라우저는 사용자를 이 URL의 페이지로 리다이렉트시키지만 리소스에 대한 링크가 업데이트 되지 않는다. 참고 자료 https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/301 https://developer.mozilla.org/ko/docs/Web/HTTP/Status/302
L4와 L7 2가지가 있다. L4는 TCP, UDP 정보(특히 포트 넘버)기반으로 로드 밸런싱을 수행한다. L7는 애플리케이션 계층의 프로토콜 정보를 기반으로 수행한다. Nginx에서 수행하는 리버스 프록시가 유사한 기능을 가지고 있다. 한 서버에 장애가 발생했을 때, 다른 서버를 통해 서비스를 제공할 수 있다. 동일한 서비스를 다수의 서버에 부하를 분산시킨다.
문제가 되는 이유 수평적 확장 관점에서 REST API와 WebSocket의 가장 큰 차이점은 아무래도 상태 관리다. REST API는 서버에서 상태를 저장하지 않기 때문에 스케일 아웃을 하는데 문제가 없다. 하지만 WebSocket의 경우에는 서버에서 세션을 저장하고 가지고 있어야한다. 따라서 클라이언트가 기존에 세션을 저장해둔 서버(BACKEND #1)가 아닌 다른 서버(BACKEND #2)로 메시지를 보낸다면 세션을 저장하고 있지 않기 때문에 처리하지 못할 것이다. 처리 방법 #1: Sticky Session Sticky Session이란 클라이언트가 첫 요청을 보낸 시점에 로드 밸런서에서 특정 서버를 하나 지정해서 처리하게 해주고, 이 클라이언트는 이후의 요청들을 전부 이전에 처리해준 서버에게 보내도록 하는 기법이다....
목표 WebRTC가 무엇인지 이해한다. WebRTC의 전체적인 구조를 이해한다. WebRTC 통신을 하기 위한 전체적인 과정을 이해한다. WebRTC란? WebRTC는 P2P 통신을 지원해주는 웹 표준이다. 오픈소스이기 때문에 지속적으로 발전되고 있다. 대부분의 최신 브라우저에서 사용가능하다. 브라우저뿐만아니라 모바일 애플리케이션에서도 사용가능하다. WebRTC는 주로 음성, 영상 통화에서 사용되고 그 뿐만 아니라 다양한 데이터를 전달할 때 사용할 수 있다. 서버를 통해 데이터를 받아야되는 WebSocket과 달리, P2P 통신으로 이루어지기 때문에 서버 과부하 문제를 해결할 수 있고, 개인 정보 보호의 이점도 가지고 있다....
SSL(Secure Sockets Layer)은 보안 소켓 계층 이라는 뜻으로 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 Netscape 사에서 개발한 인터넷 통신 규약 프로토콜이며, TLS(Transport Layer Security)는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜로 이는 SSL3.0을 보다 안전하게 하고 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다. 추후에 추가적인 학습이 필요하다. 참고 자료 https://waspro.tistory.com/161
목적 TCP를 사용하는 두 호스트가 있을 때, 발신자의 전송 속도가 너무 빨라서 수신자의 버퍼를 오버플로우 시키는 경우를 방지하기 위한 목적이다. 슬라이딩 윈도우 TCP는 흐름 제어를 위해 슬라이딩 윈도우 기법을 사용한다. TCP 윈도우는 데이터의 일부를 받았다는 ACK 패킷을 받기 전에 발신자가 보낼 수 있는 데이터의 크기다. 발신자는 자신의 윈도우 안에 있는 패킷들을 모두 보낼 수 있으며, 각 패킷에 대해서 타임아웃 타이머를 시작해야된다. 수신자로부터 ACK 패킷을 받게되면, ACK 번호만큼 윈도우를 오른쪽으로 밀 수 있다....
연결 과정에서는 3-way 핸드셰이크인데, 연결 종료시에는 왜 비효율적으로 4-way로 동작하는지 의문이 들었다. 그 이유는 클라이언트가 서버에게 연결 종료 요청을 해도 서버는 클라이언트에게 보내야될 데이터가 남아 있을 수 있기 때문이다. 4-way 핸드셰이크의 과정을 상세히 적게된다면 아래와 같다. 클라이언트가 서버에거 FIN 패킷을 보낸다. 서버가 클라이언트에게 ACK 패킷을 보낸다. 서버가 클라이언트에게 보내야 될 남은 데이터들을 보낸다. 서버가 클라이언트에게 FIN 패킷을 보낸다. 클라이언트가 서버에게 ACK 패킷을 보낸다. 참고 자료 https://velog.io/@arielgv829/CS-network-TCP-3-way-handshake-4-way-handshake https://stackoverflow.com/questions/46212623/why-tcp-termination-need-4-way-handshake
이를 이해하기 위해서는 멱등성이라는 개념을 알아야된다. 멱등성은 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니는지를 나타내는 성질이다. 대표적으로 GET, PUT, DELETE가 멱등성을 가지고, POST, PATCH는 멱등성을 가지지 않는다. PUT의 경우에는 요청의 body 내용을 그대로 리소스를 교체하게 되지만, PATCH는 사이드 이펙트가 있는 업데이트다. https://junroot.github.io/programming/REST/#http-메서드를-사용하여-요청의-의미를-가지게-하기
목표 OAuth2.0 이 무엇인지 이해한다. OAuth2.0 의 동작 방식을 이해한다. OAuth2.0 Open Authorization 웹 사이트나 애플리케이션이 다른 웹앱에 호스팅하는 리소스에 접근할 수 있도록 설계된 표준이다. 현재 온라인 인증에 대한 사실상 업계 표준으로 자리 잡고 있다. OAuth2.0 의 구성요소 Resource Owner: 애플리케이션이 자신의 계정에 접근할 수 있도록 권한을 부여하는 사용자 사용자 계정에 대한 접근 권한은 부여된 권한의 scope로 제한된다. Client: 사용자 계정에 액세스하려는 애플리케이션 사용자 계정에 접근하기 위해 Resource Owner의 승인이 필요하다....
아티클 마다 NIC(Network Interface Card)를 설명하는 계층이 달라서 혼란스러웠다. NIC가 어떤 레이어인지 정리해보자. NIC는 1계층이다? 1계층의 목적인 전기신호를 데이터로 변환하는 역할을 NIC가 하고있다. 따라서, NIC는 1계층 장비이다. NIC는 2계층이다? NIC에는 MAC 주소가 있기 때문이다. MAC 주소는 2계층에서 다루어지는 주소다. MAC 주소를 기반으로 전송 받은 데이터를 다음 레이어로 보낼지 말지 선택하기 때문에 2계층이다. 결론 나는 1계층 및 2계층이라고 결론을 지을 것이다. 자료를 검색할수록 각자 다른 결론을 내고 있기 때문에 정답이 없는 문제라고 생각한다....
탄생 배경 HTTP/1.1 클라이언트가 웹 서버와 정보 교환을 하기위해 만드러진 프로토콜이다. 클라이언트가 서버에게 GET이나 POST 같은 메소드와 함께 요청을 보내면, 서버는 HTML이나 이미지 같은 리소스를 다시 클라이언트에게 보낸다. 이렇게 하나의 요청과 응답을 주고 받는 과정에는 한 개의 애플리케이션 레이어 프로토콜이 사용된다고 생각하면 된다. HTTP/1.1은 아래와 같이 텍스트 기반 형식으로 메시지를 보낸다. GET /index.html HTTP/1.1 Host: www.example.com HTTP/2 Google에서 개발한 SPDY라는 프로토콜을 기반으로 시작되었다. HTTP/2는 압축, 멀티플렉싱, 우선 순위 지정과 같은 기술을 사용해 웹 페이지의 로딩 시간을 줄였다....
목표 SameSite 쿠키가 무엇인지 이해한다. SameSite 쿠키의 정책들을 이해한다. SameSite 쿠키 HTTP 쿠키에 사용할 수 있는 속성으로 cross-site로 요청을 보낼 때 해당 쿠키를 보낼 수 있을지 설정할 수 있다. CSRF 공격에 대한 대응으로 사용할 수 있는 속성이다. SameSite 속성의 쿠키를 설정하려면 아래와 같이 명시하면 된다. Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict SameSite 정책 Strict: 크로스 사이트 요청에 항상 전송하지 않는다. 퍼스트 파티 쿠키만 전송된다. Lax: 이미지나 iframe 에서는 크로스 사이트에 전송하지 않지만, 해당 사이트로 이동할 때 쿠키가 전송된다....
이번에는 현재 IETF의 인터넷 초안 상태인 HTTP/3에 대해서 알아본다. HTTP/3는 기존의 HTTP 버전들과 다르게 TCP를 사용하지 않는다. Transport layer에서 TCP가 아닌 QUIC을 사용한다. QUIC은 Quick UDP Internet Connection의 약자로 구글에서 개발한 UDP기반의 프로토콜이다. 이 QUIC에서 제공하는 기능에는 어떤 것이 있을까. 보안 기존에 TCP + HTTP/2를 사용할 때는 보안을 위해 별도의 TLS 레이어가 필요했다. QUIC은 자체적으로 보안 기능을 내장하고 있어 별도의 TLS 레이어를 둘 필요가 없어졌다. 이렇게 결합하면 어떤 이점이 있을까? 기존의 TCP + TLS의 경우에는 클라이언트와 서버가 연결을 시작할 때 TCP의 3-Way Handshake와 TLS 자체의 Handshake가 따로 필요했었다....