자 그럼 HTTP의 약점을 먼저 알아보면서 시작하겠습니다.

HTTP의 약점

이 약점은 HTTP만이 아닌, 다른 암호화하지 않은 프로토콜에도 공통되는 문제입니다.

1. 평문이기 때문에 도청 가능

HTTP를 사용한 리퀘스트나 리스폰스 통신 내용은 HTTP 자신을 암호화 하는 기능은 없기 때문에 통신 전체가 암호화 되지는 않습니다.

도청이 가능하다?

도청이 가능하다는게 무슨소리냐?하면 TCP/IP는 구조상 전부 통신 경로를 엿볼 수 있습니다. 인터넷은 전 셰게와 이어져 있기 때문에, 통신 경로 상에 있는 라우터들이 자신 개인의 케이블이나 컴퓨터 등일 수가 없죠.

통신 내용을 엿본다는 것은 암호화도니 통신에서도 암호화되지 않은 통신도 같습니다. 음.. 암호화된 통신을 엿본다는 것은 메시지속의 의미는 볼 수 없지만 암호화된 상태의 메시지는 볼 수 있다는것이죠.

같은 세그먼트의 통신을 도청하는 것은 그렇게 어려운일이 아니라고 합니다. 네트워크 상을 흐르고 있는 패킷을 수집하는 것 만으로도 도청할 수 있습니다. 패킷을 수집하려면 패킷 캡쳐나 패킷 스니퍼라는 툴을 사용해야합니다.

패킷 캡쳐

패킷 스니퍼

1-1. 도청 피하기

도청을 피할 수는 없습니다. 하지만 도청을 해도 내용을 볼 수 없게는 할 수 있습니다. 바로 암호화 방식입니다.

통신 암호화

첫번째 방법은 암호화 방식입니다. HTTP에는 암호화 구조는 없지만 SSL이나 TLS라는 다른 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있습니다.

SSL 등을 이용해 안전한 통신로를 만들어 놓고 그 통신로로 통신을 하는 방법입니다. 마치 터널과 비슷한 방식인 것 같습니다.

이렇게 SSL 등을 이용해 안전한 통신로를 확립하고 나서 그 통신로를 사용해 HTTP 통신을 합니다. HTTP 프로토콜에 SSL을 조합한 방식을 흔히들 알고있는 HTTPS(HTTP + SSL)이라고 부릅니다.

콘텐츠 암호화

다른 한 가지는 통신하고 있는 콘텐츠의 내용 자체를 암호화해 버리는 방법입니다.

HTTP에 암호화 기능은 없기 때문에 HTTP를 사용해서 운반하는 내용을 암호화 하는 것입니다. 즉, HTTP 메시지에 포함되는 콘텐츠만 암호화 하는 것입니다.

이 경우, 클라이언트에서 HTTP 메시지를 암호화해서 출력하는 처리가 필요하게 됩니다. 물론, 콘텐츠의 암호화를 유효하게 하려면 클라이언트와 서버가 암호화된 콘텐츠를 복호화하는 기능을 가지고 있어야하는데, 평상시에 유저가 사용하는 브라우저나 웹 서버가 이런 이런 기능을 가지고 있기는 어렵습니다.

2. 통신 상대를 모르기 때문에 위장 가능

HTTP는 통신 상대를 모르고 통신한다는 것을 알고 계셨나요?

HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않습니다. 리퀘스트를 보낸 서버가 정말로 URI에서 지정된 호스트인지 아닌지, 리스폰스를 반환한 클라이언트가 정말 리퀘스트를 출력한 클라이언트인지 아닌지 모른다는 것입니다.

누구나 리퀘스트 할 수 있다.

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 떄문에 누구든지 르퀘스트를 보낼 수 있습니다. 또한 서버는 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환합니다.

이것은 매우 간단한 구조이기에 장점이라면 장점일 수는 있겠지만, 통신하는 상대를 모른다는 약점이 있습니다. 이 약점들도 여러가지인데 아래와 같습니다.

• 위장한 웹 서버일 우려가 있다. - 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지 아닌지를 확인할 수 없다
• 위장한 클라이언트일 우려가 있다. - 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지 아닌지를 확인할 수 없다.
• 통신하고 있는 상대가 접근이 허가된 상대인지 아닌지를 확인할 수 없다.
• 어디의 누가 리퀘스트를 했는지 알 수 없다.
• D-Dos 공격을 방지할 수 없다. - 의미없는 리퀘스트라도 수신하게 된다.

SSL을 더 자세히

SSL을 쉽게 말하자면 상대를 확인하는 증명서라고 보면 편합니다. 사람으로 따지면 주민등록증..? 네.. 그런겁니다.

HTTP에서는 상대를 알 방법이 없기 때문에 SSL이라는 것으로 상대를 확인합니다.

증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명합니다. 또 그 증명서를 위조하는 것은 기술적으로 불가능한 것은 아닌데, 상당히 어렵습니다.

이렇게 상대의 서버나 클라이언트가 가진 증명서를 확인함으로써 통신 상대가 내가 통신하고자 하는 상대인지 아닌지를 판단할 수 있습니다.

3. 완전성을 증명할 수 없기 때문에 변조 가능

완전성이란? 정보의 정확성

그것을 증명할 수 없다는 것은 정보가 정확한지 아닌지를 확인할 수 없음을 의미합니다.

클라이언트에게서 받은 리퀘스트의 내용이 다를지도 모른다.

HTTP가 완전성을 증명할 수 없다는 것은 클라이언트가 서버에게 또는 서버가 클라이언트에게 전달한 리퀘스트나 리스폰스가 상대가 수신할 때까지의 사이에 변조되었을지 안되었을지 모른다는 이야기입니다.

변조되었다고 하더라도 이 사실을 알 수는 없죠.

이렇게 공격자가 리퀘스트나 리스폰스를 뺐어서 내용을 변조하는 공격을 Man-in-the-Middle 공격이라고 합니다.

따라서 HTTPS는?

HTTPS = (HTTP + 암호화 + 인증 + 완전성 보호)라고 볼 수 있겠네요.

자 오늘은 HTTP의 약점을 알아보고 SSL 방식으로 이 약점들을 보완하는 방식에 대해서 알아보았습니다.

HTTP/1.1에서는 하나의 HTTP 서버에 여러 개의 웹 사이트를 실행할 수 있습니다. 예를 들면, 웹 호스팅을 제공하고 있는 사업자는 1대의 서버에 여러 고객의 웹 사이트를 넣을 수 있습니다.

고객마다 다른 도메인을 가지고, 다른 웹 사이트를 실행할 수 있는 것이죠. 이것은 가상 호스팅(Virtual Host)라는 기능을 사용하고 있기 때문입니다.

가상 호스팅을 사용하면 실제론 서버가 한 대이지만, 가상으로 서버가 여러대 있는 것 처럼 설정이 가능한것이죠.

인터넷에서 도메인명은 DNS에 의해서 IP 주소로 변환되고 나서 액세스하게 됩니다. 이 과정은 아래와 같습니다.

Ex)

• 클라이언트 : DNS에 https://www.google.com/ 도메인 전달
• DNS : 전달받은 도메인을 10.52.xx.xx IP 주소로 변환

DNS가 도메인을 IP 주소로 변환하였기 떄문에, 결국은 리퀘스트가 IP 주소를 기준으로 액세스하게 됩니다.

근데 위에서 말한 가상 호스팅을 사용하는 상황이라면, 한 대의 서버 안에서 여러개의 호스트가 있기에 IP 주소는 같을텐데, 이런 경우 어느 쪽에 대한 액세스인지 알 수 없습니다.

따라서 HTTP 리퀘스트를 보내는 경우에는 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나, 반드시 Host 헤더 필드에서 지정해야 합니다.

통신을 중계하는 프록시, 게이트웨이, 터널

HTTP는 클라이언트와 서버 이외에 프록시, 게이트웨이, 터널과 같은 통신을 중계하는 프로그램과 서버를 연계하는 것도 가능합니다.

이러한 프로그램과 서버는 그 다음에 있는 다른 서버에 리퀘스트를 중계하고, 그 서버로부터 받은 리스폰스를 클라이언트에 반환하는 역할을 담당합니다.

프록시

프록시는 클라이언트와 서버의 양쪽 역할을 하는 중간 다리의 역할입니다. 클라이언트가 서버에 리퀘스트를 보내면 프록시 서버를 걸쳐서 오리진 서버에 도착하죠.

오리진 서버 : 리소스 본체를 가진 서버

오리진 서버에 도착한 리퀘스트는 다시 프록시 서버를 걸쳐서 클라이언트에 돌아옵니다.

당연하게도 여러대의 프록시 서버를 경유하는 것도 가능합니다.

프록시 서버를 사용하면 좋은점이 있는데, 바로 캐싱입니다. 캐싱은 CS에서도 자주 등장하고, JPA 같은 기술들에서도 비슷하게 적용되는 사례들이 많습니다.

캐싱에 대해서는 아래서 더 자세히 설명하겠습니다.

프록시의 사용 방법은 여러 가지가 있는데, 크게 2가지로 나뉩니다.

프록시의 사용 방법

1. 캐시를 하는지 안하는지 여부 판단
2. 메시지를 변경 하는지 안하는지 여부 판단

프록시 - 캐싱 프록시

프록시로 리스폰스를 중계하는 때에는 프록시 서버 상에 리소스 캐시를 보존해 두는 타입의 프록시입니다.

캐시를 간단하게 설명하자면 오리진 서버에 도달해서 한번 사용한 리소스를 프록시 서버에 보존해 두고 다음에 사용할 때 오리진 서버가 아닌 프록시 서버에서 캐시를 리스폰스로 돌려주는 방식입니다.

당연히 먼 곳까지 안가고 바로 앞에있는 곳에서 리스폰스를 받아오니 속도가 더 빨라집니다.

Ex) 처음 웹 페이지를 요청했을 때와 한번 더 같은 페이지를 요청했을 때 시간차이가 나는 것

하지만 캐시 서버에 캐시가 있는 경우라도 같은 리소스의 리퀘스트에 대해서 항상 캐시를 돌려 준다고는 말할 수 없는데요.

그 이유는 캐시에 유효기간이 있기때문입니다. 이것은 캐시되어 있는 리소스의 유효성과 관계가 있습니다.

etc) 클라이언트도 인터넷 임시 파일이라고 불리는 캐시가 있습니다.

프록시 - 투명 프록시

프록시로 리퀘스트와 리스폰스를 중계할 때 메시지 변경을 하지 않는 타입의 프록시를 투명 프록시라고 합니다.

반대로 메시지에 변경을 하는 타입을 비투과 프록시라고 합니다.

게이트웨이

게이트웨이의 동작은 프록시와 거의 같은데요, 게이트웨이는 다른 서버를 중계하는 서버로 클라이언트로부터 받은 리퀘스트를 리소스를 보유한 오리진 서버인 것 마냥 받습니다.

이게 무슨 말이냐면 게이트웨이는 "서버인 척 하는 중간다리"라고 생각하시면 될 것 같습니다.

또한 게이트웨이는 클라이언트 사이를 암호화하는 방식으로 통신의 안전성을 높입니다.

예를 들면 게이트웨이는 데이터베이스에 접속해서 데이터를 얻는데 사용하거나, 보안이 중요한 결제 시스템등에 사용됩니다.

터널

터널은 눈에 보이지 않는 투명한 개념입니다. 터널은 여규에 따라서 다른 서버와의 통신 경로를 확립합니다.

이 떄 클라이언트는 암호화 통신을 통해 서버와 안전하게 통신하기 위해 사용합니다.

터널 자체는 리퀘스트를 해석하려고 하지 않으며 리퀘스트를 받은 그대로 다음 서버에 넘겨줍니다. 터널은 통신중인 양쪽 끝의 접속이 끊어질 때에 종료됩니다.

한마디로 터널은 -> 안전한 통신로를 확립해주는 개념 (터널을 통해서 리퀘스트가 이동하면 안전하다고 생각하면 됩니다.)

HTTP 1.1 기준으로 작성한 글입니다.

쿠키는 왜 만들어졌을까?

HTTP는 상태를 유지하지 않는 stateless 프로토콜

HTTP는 상태를 계속 유지하지 않는 스테이트리스(stateless) 프로토콜입니다. HTTP 프로토콜 독자적으로, request와 response를 교환하는 동안에 상태를 관리하지 않는것인데요.

이는 이전에 보냈던 리퀘스트나 되돌려준 리스폰스에 대해서 전혀 기억하지 못한다는 뜻입니다.

이는 많은 데이터를 빠르고 정확하게 처리하는 범위성(scalability)을 확보하기 위해서 이렇게 설계되어 있는 것입니다.

하지만 장점만 보고 이런 stateless한 프로토콜을 사용하기에는 단점이 너무나도 컸는데, 예를 들면 로그인입니다.

로그인이 필요한 서비스의 경우 당연하게도 다른페이지로 이동하더라도 로그인 상태를 유지해야할 의무가 있습니다.

하지만 stateless 프로토콜인 HTTP/1.1은 상태를 유지하지 않기 때문에 범위성은 가져오되 상태 관리를 할 수 있도록 해주는 쿠키(Cookie)라는 기술을 도입했습니다.

쿠키(Cookie)란?

쿠키는 리퀘스트와 리스폰스에 쿠키 정보를 추가해서 클라이언트의 상태를 파악하기 위한 시스템입니다.

쿠키는 서버에서 리스폰스로 보내진 Set-Cookie라는 헤더 필드에 의해 쿠키를 클래이언트에 보존하게 됩니다. 다음 번에 클라이언트가 서버로 리퀘스트를 보낼 때 자동으로 쿠키 값을 넣어서 송신하죠.

그렇게되면 서버가 쿠키를 통해 이전의 리퀘스트와 리스폰스의 상태를 확인할 수 있게됩니다.

순서로보면 아래와 같습니다.

1. 클라이언트가 서버에게 리퀘스트 송신
2. 리스폰스에 Set-Cookie로 쿠키를 붙여서 송신
3. 클라이언트가 서버에게 쿠키를 붙여서 다시 서버에게 리퀘스트 송신
4. 서버가 쿠키를 통해서 req, res 이전 상태 확인

인터넷을 포함하여 일반적으로 사용하고 있는 네트워크는 TCP/IP라는 프로토콜에서 움직이고 있습니다.

TCP/IP는 프로토콜의 집합

컴퓨터와 네트워크 기기가 상호간에 통신하기 위해서는 서로 같은 방법으로 통신해야합니다.

따라서 서로 다른 하드웨어와 운영체제등을 가지고 통신하기 위해서는 규칙이 필요한데, 이러한 규칙을 프로토콜이라 부릅니다.

프로토콜에는 여러 가지가 있는데, 케이블 규격, IP 주소 지정 방법, 목적지에 도달하는 순서 등등..

이렇게 인터넷과 관련된 프로토콜들을 모은것을 TCP/IP라고 부르며 대표적으로 여러분들이 잘 아는 HTTP 프로토콜도 포함되어 있습니다.

TCP/IP는 계층으로 이루어져있다?

TCP/IP에서 중요한 개념 중에 하나가 계층(layer)입니다. TCP/IP의 계층은 아래와 같이 나눠져있습니다.

• 애플리케이션 계층
• 트랜스포트 계층
• 네트워크 계층
• 링크 계층

TCP/IP 계층화의 장점

1. 여러개의 프로토콜들로 이루어져있기 때문에 어디선가 사양이 변경되었을 때 해당 계층만 바꾸면 된다.
2. 각 계층은 계층이 연결되어 있는 부분만 결정되어 있어, 각층의 내부를 자유롭게 설계할 수 있다.
3. 설계를 편하게 할 수 있다.

애플리케이션 계층

애플리케이션 계층은 유저에게 제공되는 애플리케이션에서 사용하는 통신의 움직임을 결정합니다.

TCP/IP에는 여러 가지의 공통 애플리케이션이 준비되어 있습니다. Ex) FTP, DNS, HTTP ..

트랜스포트 계층

트랜스포트 계층은 애플리케이션 계층에 네트워크로 접속되어 있는 2대의 컴퓨터 사이의 데이터 흐름을 제공합니다.

트랜스포트 계층에서는 서로다른 성질을 가진 TCP와 UDP 두가지 프로토콜이 있습니다.

네트워크 계층

네트워크 계층은 네트워크 상에서 패킷의 이동을 다룹니다.

패킷이란? 전송하는 데이터의 최소 단위

이 계층에서는 어떤 경로를 걸쳐서 상대의 컴퓨터까지 패킷을 전송시킬지 정하기도 합니다.

인터넷의 경우에 상대 컴퓨터에 도달하는 동안에 여러 대의 컴퓨터와 네트워크 기기를 거쳐서 상대방에게 전달됩니다.

따라서 여러 컴퓨터와 네트워크 기기중 어떤 길로 갈지 하나의 길을 결정하는 것이 네트워크 계층의 역할이 됩니다.

링크 계층

네트워크에 접속하는 하드웨어적인 면을 다룹니다. 운영체제가 하드웨어를 제어하기 때문에 디바이스 드라이버와 네트워크 인터페이스 카드를 포합합니다.

물리적으로 보이는부분(케이블 등등..)도 포함됩니다. 쉽게말하면 하드웨어적인 부분들은 모두 TCP/IP 계층중에서 링크 계층의 역할입니다.

TCP/IP 통신은 U자형

TCP/IP 통신을 할 때는 계층을 순서대로 거쳐 상대와 통신을 합니다. 송신(보내는 쪽)은 애플리케이션 계층에서부터 내려가고, 수신(뱓는 쪽)은 애플리케이션 계층으로 올라갑니다.

예를 들어 설명해보겠습니다.

1. 애플리케이션 계층 : 어느 웹 페이지를 보고싶다고 리퀘스트를 지시합니다.

2. 트랜스포트 계층 : 애플리케이션 계층에서 받은 데이터를 작게 여러조각으로 조각내어 번호표를 부여하여 네트워크 계층에 전송합니다.

3. 네트워크 계층 : 수신지 MAC 주소를 추가해서 링크 계층에 전달합니다. (MAC 주소는 아래서 설명합니다.)

이렇게 송신측의 준비는 끝났습니다. 수신은 이와 반대 순서로 진행된다고 보면 됩니다. 사진으로 보면 아래와 같습니다.

• 송신 : 각 계층을 거칠 때는 반드시 헤더로 불려지는 해당 계층마다 해당 계층에 필요한 정보를 추가합니다.

• 수신 : 각 계층을 거칠 때마다 반드시 해당 계층마다 사용한 헤더를 삭제합니다.

HTTP와 깊은 관계인 IP / TCP / DNS

IP, TCP, DNS는 HTTP와 관계가 정말 깊습니다. 따라서 세 개의 프로토콜에 대해서 설명을 해보겠습니다.

IP - 배민 라이더

IP는 계층으로 말하자면 네트워크 층에 해당됩니다. IP는 TCP/IP라는 명칭의 일부가 될 정도로 중요한 프로토콜입니다.

IP와 IP 주소는 다른 개념입니다. IP는 프로토콜의 명칭입니다.

IP의 역할은 개개의 패킷을 상대에게 전달하는 것입니다. 상대방에게 전달하기까지 여러 가지 요소가 필요한데, 그 중에서도 IP 주소와 MAC 주소가 중요합니다.

• IP 주소 : 각 노드에 부여된 주소
• MAC 주소 : 각 네트워크 카드에 할당된 고유의 주소

IP 주소와 MAC 주소는 연관되어있으며 IP 주소는 변경가능하지만, MAC 주소는 변경 불가능합니다.

ARP와 MAC

IP 통신은 MAC 주소에 의존해서 통신을 합니다.

인터넷에서 통신 상대가 같은 랜선 내에 있을 경우는 많지 않기 때문에 여러 대의 컴퓨터와 네트워크 기기를 통해서 상대방에게 도착합니다.

그렇게 여러 컴퓨터와 네트워크 기기를 지나는 동안 다음 목적지의 MAC 주소를 통해 목적지를 찾아갈 수 있는것입니다.

ARP : 주소 문제를 해결하기 위한 프로토콜 중 하나이며 수신지의 IP 주소를 바탕으로 MAC 주소를 조사할 수 있다.

Ex) 송신 : 52.54.xx.xx 주소에 패킷을 보내고 싶음 ARP : 52.54.xx.xx 주소에 도달하기 위해 거치는 중간 라우터들의 MAC 주소를 조사해서 패킷을 목적지에 도달시킴

신뢰성을 담당하는 TCP

TCP는 계층으로 말하자면 트랜스포트 계층에 해당하는데, 신뢰성 있는 바이트 스트림 서비스를 제공합니다.

바이트 스트림 서비스? 용량이 큰 데이터를 보내기 쉽게 TCP 세그먼트라고 불리는 단위 패킷으로 작게 분해하여 관리하는 서비스

신뢰성 있는? 상대방에게 보내는 서비스

따라서 TCP는 대용량의 데이터를 보내기 쉽도록 작게 분해하여 상대에게 보내고, 정확하게 도착했는지 확인하는 역할을 담당하고 있습니다.

신뢰성이 있도록 상대에게 확실하게 데이터를 보내기 위해서 TCP는 쓰리웨이 핸드셰이킹이라는 방법을 사용합니다. 이 글에 정리해 놓았습니다.

이름 해결을 담당하는 DNS

DNS는 HTTP와 같이 응용 계층 시스템에서 도메인 이름과 IP 주소 이름 확인을 제공합니다. 컴퓨터는 IP 주소와는 별도로 호스트 이름과 도메인 이름을 붙일 수 있습니다.

사용자들은 숫자를 나열하는 IP 주소보다 영문과 숫자 등으로 표기한 이름이 더 친숙합니다. 하지만 컴퓨터들은 숫자를 나열하는 방식이 더 친숙한데 이러한 문제를 해결하기 위해 DNS가 있습니다.

DNS는 도메인명에서 IP 주소를 조사하거나 반대로 IP 주소로부터 도메인명을 조사하는 서비스를 제공합니다.

당연스럽게도 HTTP의 버전업이 이루어 지면서 속도가 빨라졌습니다.

이는 HPACK 압축으로 헤더를 줄이고 응답의 우선순위를 정해 응답을 보내는 방식을 사용하는 것이 HTTP 1.1보다 더 빠른 응답속도를 기록할수 있는 이유입니다.

헤더를 줄이고..~ 우선순위를 정하고 하는 것은

헤더를 줄이고..~ 우선순위를 정하고 뭐라는거야

결국 HTTP 1.1의 단점을 보완했다는 이야기입니다. HTTP 1.1의 단점은 아래와 같습니다.

• Connection 한 개당 하나의 요청을 처리하도록 설계됨

  • 동시에 리소스를 주고 받을 수 없음
  • request와response가 순차적으로 이루어짐
  • HTTP 문서 내에 많은 리소스(image, css, script)를 처리하려면 요청할 리소스의 개수에 비례하여 대기시간이 길어짐

• HOL(Head Of Line) Blocking이 발생할 수 있다. HOL 블로킹이란 네트워크에서 같은 큐에있는 첫번째 패킷이 지연되므로써 성능이 저하되는 현상이다.

• RTT(Round Trip Time) 증가 첫번째 단점에서 말한 특성때문에 매번 요청 별로 Connection을 만들게 되고 TCP상에서 동작하는 HTTP의 특성상 3-way handshake가 반복적으로 일어나서 불필요한 RTT 증가와 네트워크 지연을 초래하여 성능을 지연시킨다.

• 무거운 Header 구조 매 요청마다 중복된 헤더 값을 전송하게 되며, 서버 도메인에 관련된 쿠키 정보도 헤더에 함께 포함되어 전송된다. 이러한 반복적인 헤더 전송, 쿠키 정보로 인해 헤더 크기가 증가한다.

그래서 이런걸 보완한 HTTP 2.0

HTTP2.0은 HTTP1.1을 완전하게 재작성한 것이 아니라 프로토콜의 성능에 초첨을 맞춰 수정한 버전이라고 생각하면 됩니다.

특히 지연시간이나 네트워크, 서버 리소스 사용량 등과 같은 성능 위주로 개선되었습니다.

주요 특징

• Multiplexed Streams : connection 한 개로 동시에 여러 개의 메시지를 주고 받을 수 있도록 개선
• Stream Prioritization : 리소스 간의 의존관계에 따른 우선순위를 설정하여 리소스 로드 문제를 해결함
• Header Compression : 헤더 정보를 HPACK 방식으로 압축한다.

references

• https://bakjuna.tistory.com/129
• https://velog.io/@wiostz98kr/HTTP1.1%EA%B3%BC-HTTP2.0%EC%9D%98-%EC%B0%A8%EC%9D%B4-e2v4x4t1

Dependency 추가하기

Scheduler는 기본적으로 org.springframework.scheduling 패키지에 있으므로 gradle 기준 다음과 같이 의존성을 추가하면 된다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
}

maven의 경우 다음과 같다.

<dependency> 
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

스케줄링 활성화

스케줄링 기능을 활성화하기 위해서 다음과 같이 configuration 클래스 혹은 지금처럼 애플리케이션 메인 클래스에 @EnableScheduling를 추가한다.

@EnableScheduling
@SpringBootApplication
public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
}

컴포넌트 등록

@Component
public class ScheduledTasks {

}

기본적으로 @Component를 사용해서 컴포넌트로 등록해도 되지만, @Component를 내장하고 있는 @Service와 같은 어노테이션들로도 등록이 가능하다.

크론 문법으로 반복 주기 지정하기

스케쥴러를 이용하기 위해서는 여러가지 방법들이 있지만, 난 그중에서 보기쉽고 직관적인 @Scheduled + cron 문법을 사용해서 지정해 보겠다.

스케줄러가 적용된 메서드의 반환타입은 void여야 합니다.

@Scheduled(cron = "0 0 0 * * *")
public void ScheduledTasksMethod() {
    log.info("{}에 실행되었습니다.", formatter.format(LocalDateTime.now()));
}

참고로 위에서 사용한 0 0 0 * * * 은 매일 자정이라는 뜻입니다.

출처

이렇게 스케줄러를 사용해서 일정 주기마다 실행되는 메서드를 만들어 보았다. 크론 문법은 아직 미숙하기 때문에 더 파봐야겠다..

100 Continue

이 임시적인 응답은 지금까지의 상태가 괜찮으며 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려준다.

101 Switching Protocol

이 코드는 클라이언트가 보낸 Upgrade(en-US) 요청 헤더에 대한 응답에 들어가며 서버에서 프로토콜을 변경할 것임을 알려준다.

102 Processing (WebDAV (en-US))

이 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려준다.

103 Early Hints

이 상태 코드는 주로 Link(en-US) 헤더와 함께 사용되어 서버가 응답을 준비하는 동안 사용자 에이전트가(user agent) 사전 로딩(preloading)을 시작할 수 있도록 한다.

Response Status - 2**

200 OK

요청이 성공적으로 됨을 알림.

성공의 의미는 HTTP 메소드에 따라 달라진다.

• GET: 리소스를 불러와서 메시지 바디에 전송
• HEAD: 개체 해더가 메시지 바디에 있음
• PUT 또는 POST: 수행 결과에 대한 리소스가 메시지 바디에 전송됨
• TRACE: 메시지 바디는 서버에서 수신한 요청 메시지를 포함하고 있음

201 Created

요청이 성공적이었으며 그 결과로 새로운 리소스가 생성됨. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라온다.

202 Accepted

요청을 수신하였지만 그에 응하여 행동할 수 없다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않는다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌다.

203 Non-Authoritative Information (en-US)

이 응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선시된다.

204 No Content

요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있다.

Response Status - 3**

300 Multiple Choice (en-US)

요청에 대해서 하나 이상의 응답이 가능하다. 사용자 에이전트 또는 사용자는 그중에 하나를 반드시 선택해야 한다. 응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않는다.

301 Moved Permanently

요청한 리소스의 URI가 변경되었음을 의미한다. 새로운 URI가 응답에서 아마도 주어질 수 있다.

302 Found

요청한 리소스의 URI가 일시적으로 변경되었음을 의미한다. 새롭게 변경된 URI는 나중에 만들어질 수 있다. 그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야한다.

303 See Other (en-US)

클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때, 서버가 클라이언트로 직접 보내는 응답이다.

304 Not Modified

이것은 캐시를 목적으로 사용된다. 이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며, 그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있다.

Response Status - 4**

400 Bad Request

잘못된 문법으로 인하여 서버가 요청을 이해할 수 없음을 의미한다.

401 Unauthorized

비록 HTTP 표준에서는 "미승인(unauthorized)"를 명확히 하고 있지만, 의미상 이 응답은 "비인증(unauthenticated)"을 의미한다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 한다.

403 Forbidden

클라이언트는 콘텐츠에 접근할 권한를 가지고 있지 않다.

404 Not Found

서버는 요청받은 리소스를 찾을 수 없다. 브라우저에서는 알려지지 않은 URL을 의미한다. 이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수도 있다. 이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모른다.

405 Method Not Allowed

요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없다. 예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있다.

407 Proxy Authentication Required (en-US)

이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요하다.

408 Request Timeout

이 응답은 요청을 한지 시간이 오래된 연결에 일부 서버가 전송하며, 어떨 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 한다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어한다는 것을 의미한다.

409 Conflict

요청이 현재 서버의 상태와 충돌될 때 보낸다.

Response Status - 5**

500 Internal Server Error

서버가 처리 방법을 모르는 상황이 발생함. 서버는 아직 처리 방법을 알 수 없다.

501 Not Implemented

요청 방법은 서버에서 지원되지 않으므로 처리할 수 없다. 서버가 지원해야 하는 유일한 방법은 GET와 HEAD이다. 이 코드는 반환하면 안된다.

502 Bad Gateway

이 오류 응답은 서버가 요청을 처리하는 데 필요한 응답을 얻기 위해 게이트웨이로 작업하는 동안 잘못된 응답을 수신했음을 의미한다.

504 Gateway Timeout

이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 때 주어진다.

505 HTTP Version Not Supported

요청에 사용된 HTTP 버전은 서버에서 지원되지 않는다.

506 Variant Also Negotiates (en-US)

서버에 내부 구성 오류가 있다. 즉, 요청을 위한 투명한 컨텐츠 협상이 순환 참조로 이어진다.

507 Insufficient Storage (en-US)

서버에 내부 구성 오류가 있다. 즉, 선택한 가변 리소스는 투명한 콘텐츠 협상에 참여하도록 구성되므로 협상 프로세스의 적절한 종료 지점이 아니다.

508 Loop Detected (en-US) (WebDAV (en-US))

서버가 요청을 처리하는 동안 무한 루프를 감지함.

511 Network Authentication Required (en-US)

클라이언트가 네트워크 액세스를 얻기 위해 인증을 받아야 할 필요가 있음을 나타낸다.

HTTP Method는 크게 4가지로 나누어져있다.

• Create: 데이터 생성 (POST)
• Read: 데이터 조회 (GET)
• Update: 데이터 수정 (PUT)
• Delete: 데이터 삭제 (DELETE)

보통 GET과 POST의 차이는 명확히 구분할 수 있지만, POST와 PUT를 구분하려면 멱등성을 알아야 한다.

💡 멱등성(Idempotence)이란?

멱등성이란 여러번 수행해도 결과가 같음을 의미한다.

HTTP 메소드를 예를 들자면, GET, PUT, DELETE는 같은 경로로 여러 번 호출해도 결과가 같다.

그러나 POST는 매 호출마다 새로운 데이터가 추가된다.  따라서, POST 연산은 결과가 Idempotent하지 않지만, PUT은 반복 수행해도 그 결과가 Idempotent 하다. 

⚪️ GET

GET 메소드는 주로 데이터를 읽거나(Read) 검색(Retrieve)할 때에 사용되는 메소드이다.

만약에 GET요청이 성공적으로 이루어진다면 200(OK) HTTP 응답 코드를 리턴한다. 에러가 발생하면 상태코드 404 (Not found) 또는 400 (Bad request)를 반환한다.

HTTP 명세에 의하면 GET 요청은 오로지 데이터를 읽을 때만 사용된다고 한다. 따라서 데이터를 변경할 때는 사용하면 안된다.

Ex)

GET /post/3

데이터를 조회하는 것이기 때문에 요청시에 Body 값과 Content-Type 이 비워져있다. 조회할 데이터에 대한 정보는 URL을 통해서 파라미터를 받고 있는 모습을 볼 수 있다.

데이터 조회에 성공한다면 Body 값에 데이터 값을 저장하여 성공 응답을 보낸다.

GET은 캐싱이 가능하여 같은 데이터를 한번 더 조회할 경우에 조회 속도가 빨라진다.

🟢 POST

POST 메소드는 주로 새로운 리소스를 생성(create)할 때 사용된다. 성공적으로 작업을 완료하면 201(Created) HTTP 응답을 반환한다.

POST 메소드는 아래와 같은 특징을 가지고있다.

• 같은 POST 요청을 반복해서 했을 때 항상 같은 결과물이 나오는 것을 보장하지 않는다
• 두 개의 같은 POST 요청을 보내면 같은 정보를 담은 두 개의 다른 resource를 반환할 가능성이 높다.

Ex)

POST /user
body: 
{
  email: "example@gmail.com", 
  password: "test123!@"
}
Content-Type: "application/json"

데이터를 생성하는 것이기 때문에 요청시에 Body 값과 Content-Type 값을 작성해야한다.

URL을 통해서 데이터를 받지 않고, Body 값을 통해서 받는다.

데이터 조회에 성공한다면 Body 값에 저장한 데이터 값을 저장하여 성공 응답을 보낸다.

🔵 PUT

PUT은 리소스를 생성/수정하기 위해 서버로 데이터를 보내는 데 사용된다.

PUT은 아래와 같은 특징을 가지고있다.

• PUT 요청은 idempotent하다.
• 동일한 PUT 요청을 여러 번 호출하면 항상 동일한 결과가 생성된다.

Ex)

PUT /user/1
body: 
{
    email: "updateEmail@gmail.com", 
    password: "updatePassword123!@"
}
Content-Type: "application/json"

데이터를 수정하는 것이기 때문에 요청시에 Body 값과 Content-Type 값을 작성해야한다.

URL을 통해서 어떠한 데이터를 수정할지 파라미터 받는다. 그리고 수정할 데이터 값을 Body 값을 통해서 받는다.

🔴 DELETE

DELETE 메서드는 지정된 리소스를 삭제한다.

Ex)

DELETE /user/1

데이터를 삭제하는 것이기 때문에 요청시에 Body 값과 Content-Type 값이 비워져있다.

references

• https://devuna.tistory.com/77
• https://velog.io/@yh20studio/CS-Http-Method-%EB%9E%80-GET-POST-PUT-DELETE#1-get
• https://memostack.tistory.com/180#2.1.%20GET%20Method

이렇게 우리의 곁에서도 심심치않게 등장하며, 특히 jwt 또는 채팅에 자주 사용하곤 하는데 이녀석이 뭘까?

레디스란?

Redis란 REmote DIctionary Server의 약자이다. Remote(외부) Dictionary(key, value) Server(서버) 따라서 Redis는 외부에 있는 딕셔너리를 사용하는 서버라고 볼 수 있다.

What is Redis 🤔

• 인 메모리 데이터 구조 : List, Set, Hash, Map 등의 유형들을 인 메모리 안에 저장 할 수 있다. Redis 중 큰 특징이라 생각한다.

• 검색 시간으로 인한 지연을 방지하고 CPU 명령을 적게 사용하는 좀 더 간단한 알고리즘으로 데이터에 액세스할 수 있다

• 개발과 운영을 좀 더 쉽게 할 수 있으며 Pub/Sub 사용하여 메시징 시스템에 유용하며 불필요한 데이터를 채우지 않게하는 데 유용하다.

• 캐시를 사용하여 속도가 빠르고 정보가 사리지지 않습니다.

레디스의 필요성

• 캐시를 생성하여 액세스 시간을 줄이고 처리량을 늘려서 DB에 부담을 덜어줌

• 이벤트 속도를 측정하고 제어할 수 있음

• List를 사용하면 영구 대기열을 만들 수 있다. 자동 작업 및 차단 기능을 제공하므로 신뢰할 수 있는 메시지 브로커, 순환 목록이 필요한 다양한 애플리케이션에 사용한다.

• 패턴 매칭과 더불어 PUB/SUB이 지원이 된다고 한다. 고성능 채팅방, 실시간 코멘트 스트림 및 서버 상호 통신을 지원한다.

처음에 Jwt를 접했을 때 Jwt가 무엇이고 헤더, 페이로드, 액세스 토큰, 리프레시 토큰 등 뭐가 뭐고 얘가 이런애고 쟤는 저거 하는 애고 이론적으로는 그닥 어렵진 않았다.

하지만 백문이 불여일타라고 했다. (( 내가하고 싶은 말은 반대되긴 하지만.. 원래 백번 말하는것보다 한번 치는게 더 이해된다고 하던데, 한번 쳐보려하니 머릿속으로는 정리가 됬던 이론들이 제각각 놀기 시작했다.

물론 다른사람 블로그도 보고 깃허브도 보며 염탐을 오지게 해보긴 했지만, 사바사(사람 바이 사람)이여서 그런지 느낌은 비슷하긴해도 복붙으로 해결할 수 없는 부분들이 많았다.

스프링 부트에서 Jwt를 어떤식으로 사용하고 리프레시 토큰을 사용한 방식으로 어떻게 액세스 토큰을 재발급하는가 등등 여러가지 고난과 역경을 겪었다;

뭐 하여튼, 지금부터 내가 Jwt를 처음 배우고 스프링 부트에 적용하면서 겪었던 난관?을 소개해보겠다. 뭐 솔직히 나만 이해못하고 다른사람들은 거의 이해했을 것이다.

이 글은 Jwt를 소개하는 글이 아니라 내가 개발하면서 Jwt를 어떻게 스프링에 적용시켜야 하는지 했던 고찰이다.

스프링 부트에서 Jwt 방식으로 인증을 구현하는 이유

우리가 알고있는 대표적인 인증 처리 방식은 3가지가 있다.(쿠키, 세션, Jwt) Jwt는 개인적으로 셋중에서는 제일 까다롭게 느껴졌다.

그래서 이런생각을 해봤다. 셋 다 인증되는건 똑같은데 왜 Jwt를 써야하냐?

이 궁금증이 해결되지 않으면 나에게 있어서 Jwt란 다른 2가지 인증 방식보다 개발 생산성만 떨어지는 인증 방식이라고 인식했을 것이다.

그래서 내가 생각하는 Jwt를 사용해야 하는 이유를 몇가지 살펴보자.

토큰 방식은 사용자가 로그인을 하면 서버에서 발행해주는 토큰을 가지고 브라우저의 저장소에 토큰을 유지시키는 방법이다. 여기서 말하는 토큰이 우리가 말하는 Jwt이다.

확장성

서버에 저장하지 않아서 서버에 확장성이 있다. 위에서 말했듯 로그인을 했을 때 해당 서버에만 요청을 보내는 것이 아닌 요청이 들어왔을 때 해당 토큰이 유효한지만 체크하면 되기 때문에 어떤 서버로 요청을 보내도 상관이 없다는 뜻이다.

정보 교환

Jwt는 당사자 간에 정보를 안전하게 전송하는 좋은 방법이다. 헤더와 페이로드를 사용하여 서명을 계산하므로 내용이 조작되지 않았는지 확인할 수도 있다.

트래픽에 대한 부담

서버에 직접적으로 관여하는 부분이 크지 않기 때문에 세션보다 트래픽에 대한 부담이 적다.

1. 토큰의 정보는 어디에?

Jwt에 대해서 뭣도 모르고 "쉬워 보이네ㅋㅋ 일단 해보자"라는 생각에 흥분하며 인텔리제이를 실행시켰던 때가 엇그제 같다. 시작하자마자 아무것도 모르고 개발을 한다는건 망상이었다.

Jwt라는 방식으로도 인증할 수 있구나 라는 생각으로 개발을 시작했었던 것 같은데 당연하겠지만 최소한의 Jwt에 관련된 이론적인 지식들은 알아야 개발이 가능하다.

다시 본론으로 돌아와서 액세스 토큰과 리프레시 토큰의 차이점은 유효시간에 있으며, 나머지 정보들은 같다.

이를 바탕으로 로그인 요청을 보내면 유효시간만 다른 토큰 2개가 반환되어야 하는데..

결론부터 말하자면 방법은 쉬웠지만 매번 바뀌는 토큰의 시간을 전역 변수로 선언해야 하는가에 대해 오래 고민했다.

시간만 따로 관리해주는 클래스를 만들어서 사용하면 더 쉽게 접근할 수 있었다.

우선 아시겠다시피 Jwt는 액세스 토큰과 리프레시 토큰이 있으며,

액세스 토큰이 만료되면, 리프레시 토큰을 통해서 액세스 토큰을 재발급 받는다.

라는 개념이 잡혀있어야 한다.

이것이 성립하려면 리프레시 토큰이 액세스 토큰보다 유효 시간이 길어야 하는것이 성립되어야 하기 때문에 리프레시 토큰의 유효 시간을 길게 잡아준다.

액세스 토큰의 유효시간을 짧게 잡는 이유는 Jwt를 발급한 후에는 만료되기 전까지는 토큰을 무효화 할 수 없기 때문에 보안이 취약하기 때문이다.

보통 액세스 토큰의 유효 시간은 약 1시간 ~ 2시간 이며, 리프레시 토큰은 짧으면 2주 ~ 한 달까지 잡기도 한다고 한다. (( 뭐 이것도 사바사이긴 함..

이제 약간의 코드를 섞어가면서 살펴보자.

gradle

dependencies {
    implementation group: 'io.jsonwebtoken', name: 'jjwt-api', version: '0.11.2'
    runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-impl', version: '0.11.2'
    runtimeOnly group: 'io.jsonwebtoken', name: 'jjwt-jackson', version: '0.11.2'
}

Jwt를 사용하기 위해서는 당연히 Jwt 라이브러리를 땡겨와야 한다.

application.yml

spring:
    security:
        jwt:
            secret: c2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQtc2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQK

HS512 알고리즘을 사용할 것이기 때문에 512bit, 즉 64byte 이상의 secret key를 사용해야 한다.

쉽게 말하면 저자리에는 그냥 아무거나 길게 적어놓으면 된다는 말임..

액세스 토큰

뭐 간단하게 토큰의 생성과 유효성 검증등을 담당할 클래스를 만들어주자.

@Component
public class JwtTokenProvider {

}

여기저기서 의존성 주입을 받으며 사용당해야 하기 때문에 @Component 어노테이션을 사용한다.

@Value("${spring.security.jwt.secret}")
private String secretKey;

@Value로 아까 yml에 작성해 놓았던 시크릿 키를 가져오자. 따로 설정을 하지 않았다면 기본 경로는 resources 아래에 있는 application.yml로 지정될 것이다.

@PostConstruct
protected void init() {
     secretKey = Base64.getEncoder().encodeToString(secretKey.getBytes());
}

@PostConstruct는 의존성 주입이 이루어진 후 초기화를 수행하는 메서드이다.

따라서 이 컴포넌트는 의존성 주입이 이루어진 후 시크릿 키가 Base64로 인코딩 될 것이다.

public String createToken(페이로드에 넣고 싶은 정보(매개변수가 몇개이든 상관없음), 토큰 유효 시간) {
        Claims claims = Jwts.claims();
        claims.put("email", email);
        Date now = new Date();

        return Jwts.builder()
                .setClaims(claims)
                .setIssuedAt(now)
                .setExpiration(new Date(now.getTime() + time))
                .signWith(getSigningKey(secretKey), SignatureAlgorithm.HS256)
                .compact();
    }

claim은 payload 부분에 들어갈 정보 조각들이다.

claim은 Registered claim, Public claim, Private claim으로 나눠진다.

나같은 경우에는 페이로드 부분에 사용자의 이메일 정보를 넣어줬다.

Jwt.builder에서는

헤더의 타입(typ), 발급 시간(iat), 만료 시간(exp), 비공개 클레임을 설정할 수 있다.

발급 시간(iat)과 만료 시간(exp)은 Date 타입만 추가가 가능하다.

비공개 클레임은 key-value 쌍으로 이루어져 있으며, 헤싱 알고리즘과 시크릿 키를 설정할 수 있다.

public String createAccessToken(페이로드에 넣고싶은 정보) {
    return createToken(페이로드에 넣고싶은 정보, 토큰 유효 시간);
}

public String createRefreshToken(String email) {
    return createToken(페이로드에 넣고싶은 정보, 토큰 유효 시간);
}

이렇게 액세스 토큰과 리프레시 토큰을 생성하는 코드를 작성해보았다.

위에서 언급했듯이 이 코드에 토큰 유효 시간만 따로 관리하는 클래스를 만들어서 적용시켜도 되고, 전역 변수로 선언해도 안될건 없다.

2. 액세스 토큰의 재발급에 대해서

내가 액세스 토큰을 리프레시 토큰을 이용해서 재발급 받는 구조를 이해 못해서 그냥 액세스 토큰을 리프레시 토큰만큼 길게 잡아서 액세스 토큰을 리프레시 토큰마냥 사용하려 했던적이 있다.

(난 처음에 엑세스 토큰이 만료되면 리프레시 토큰으로 자동 변경되는줄 알았다ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ)

하지만 리프레시 토큰은 리프레시 토큰이고 액세스 토큰은 액세스 토큰이 아닌가. 리프레시 토큰을 이용해서 액세스 토큰을 재발급한다는게 무슨 말인지 알아보자.

우선 액세스 토큰을 1시간으로, 리프레시 토큰은 2주일로 설정해놓았다고 가정하자. 따라서 액세스 토큰은 유효시간이 짧기 때문에 비교적으로 재발급 받는 빈도가 많을 수 밖에 없다.

따라서 리프레시 토큰을 사용하는 이유는 1시간마다 사용자 재로그인이라는 미친 번거로움을 없애고, 토큰 무효화 기능 관련 부하 문제를 막을 수 있다.

(리프레시 토큰마저 만료된다면, 다시 로그인해야함)

액세스 토큰과 달리 리프레시 토큰은 발급시 데이터베이스에 저장하고, 액세스 토큰을 재발급 받을 시 리프레시 토큰을 request header에 담은 후 요청을 보내고, 데이터베이스에 있는 리프레시 토큰과 같으면 새로운 액세스 토큰을 재발급 해주는 형태이다.

백문이 불여일견이라고했다. (나는 이 말을 참 좋아하는 것 같다..) 사진으로 보자.

로그인 후 액세스 토큰과 리프레시 토큰 발급

액세스 토큰 재발급

기존의 액세스 토큰이 만료됐다고 가정하고 재발급 받아야 하는 상황 처음에 로그인을 하고 발급 받았던 리프레시 토큰을 헤더에 넣어주고 요청을 보내면!

만료되지 않은 새 액세스 토큰으로 반환된다. 리프레시 토큰이 null인 이유는 같은 로그인을 했을때와 같은 responseDto로 반환했는데, 액세스 토큰만 재발급 해서 그렇다. 신경쓰지 않아도 됨..

여기에 관련된 내용은 이 포스트가 정리가 잘되어있다.

3. 매 요청마다 토큰이 만료되었는지 어떻게 확인하는가

액세스 토큰을 재발급 받으려면 우선 토큰이 만료되었는지 안되었는지 먼저 알아야한다.

액세스 토큰이 만료되었는지 안되었는지 판단하는 기능이 어려운 것이 아니었다. 이를 어떻게 매 요청마다 확인할지가 고민이었다.

이것도 결론부터 말하면 Filter에 있었는데, SecurityConfig라는 시큐리티 설정 클래스에서 스프링 시큐리티가 지원하는 필터체인 전에 실행하도록 하는 .addFilterBefore()메서드를 사용했다.

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .addFilterBefore(new JwtAuthenticationFilter(jwtTokenProvider, customUserDetailService, jwtValidateService),
                        UsernamePasswordAuthenticationFilter.class)
                .addFilterBefore(new JwtExceptionFilter(), JwtAuthenticationFilter.class);
    }

이렇게 토큰이 유효한지 판단하는 클래스와, Jwt의 정보를 필요로 하는 클래스들을 먼저 필터링 하게 만들었다.

끝내며

이번에 작성한 글은 Jwt로 어떻게 로그인을 해야하고 사용하는지 세세하게 다루기 보다는 내가 Jwt를 스프링 부트에 사용하면서 어떤걸 고민했고, 어떻게 사용해서 문제들을 풀어나갔는지에 대한 관점들이 주를 이루었다.

이번에 Jwt로 개발해보면서 Jwt 뿐만 아니라 스프링 전반적인 이해도 또한 많이 길러진 것 같다.

처음에 언급했다시피 다른사람들의 글과 코드를 많이 보았다. 내가 하던 것보다 더 좋은 방법들도 많아 보였다.

비록 이해하고 사용하자는 내 고질병 덕분에 개발부터 글까지 쓰는 시간이 오래 걸리긴 했지만, 여전히 이해하고 사용해야 한다는 생각은 달라지지 않은 것 같다.

계속 열심히 개발합시다.. 여러분 화이팅!

References

• Spring Boot Refresh Token with JWT example
• spring security jwt 사용하기
• Spring Boot jwt 사용하기 access token, refresh token 발급
• Spring boot + JWT + RefreshToken 구현하기
• JWT 인증 갱신처리
• [Spring] JWT Refresh Token을 사용한 로그인과 고찰
• [WEB] 📚 Access Token & Refresh Token 원리 (feat. JWT)
• Bamdoliro

Spring Batch는 로깅/추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리 등 대용량 레코드 처리에 필수적인 기능을 제공한다.

또한 최적화 및 파티셔닝 기술을 통해 대용량 및 고성능 배치 작업을 가능하게 하는 고급 기술 서비스 및 기능도 제공한다.

Spring Batch에서 배치가 실패하여 작업 재시작을 하게 된다면 처음부터가 아닌 실패한 지점부터 실행을 하게 된다.

또한 중복 실행을 막기 위해 성공한 이력이 있는 Batch는 동일한 Parameters로 실행 시 Exception이 발생하게 된다.

Batch 중에서도 Spring Batch로..

Spring Batch의 특징은 다음과 같다.

• 가볍고 포괄적인 배치 프레임워크
• Spring Batch는 로깅/추적, 트랜잭션 관리, 작업 처리 통계, 작업 재시작, 건너뛰기, 리소스 관리 등 대용량 레코드 처리에 필수적인 기능을 제공
• 최적화, 파티셔닝 기술로 대용량 고성능 배치 작업 가능
• 확정성이 매우 뛰어남

Job

1개의 작업에 대한 명세서이다. 어디까지가 1개의 작업인지 애매할 수 있지만 그 기준은 상황별로 재량껏 판단할 수 있다.

Job의 특징

• 1개의 Job은 여러개의 Step을 포함할 수 있다.
• Job name을 통해 Job을 구분할 수 있다.
• Job name으로 Job을 실행시킬 수 있다.
• Job Builder Factory로 쉽게 Job을 만들 수 있다.

Ex ) Job : 게임을 한다. Step 1. 컴퓨터를 켠다. Step 2. 게임에 로그인 한다. Step 3. 게임 시작을 누른다.

JobInstance

JobInstance는 Job의 실행의 단위를 나타냅니다. Job을 실행시키게 되면 하나의 JobInstance가 생성된다.

예를들어 1월 1일 실행, 1월 2일 실행을 하게 되면 각각의 JobInstance가 생성되며 1월 1일 실행한 JobInstance가 실패하여 다시 실행을 시키더라도 이 JobInstance는 1월 1일에 대한 데이터만 처리하게 된다.

JobExecution

JobExecution은 JobInstance에 대한 실행 시도에 대한 객체이다.

1월 1일에 실행한 JobInstacne가 실패하여 재실행을 하여도 동일한 JobInstance를 실행시키지만 이 2번에 실행에 대한 JobExecution은 개별로 생기게 된다.

JobExecution는 이러한 JobInstance 실행에 대한 상태, 시작시간, 종료시간, 생성시간 등의 정보를 담고 있다.

JobExecutionContext

1개의 Job 내에서 공유하는 공간(Contex)이다.

1개의 Job에 여러개의 Step이 있다면 그 Step들은 해당 공간을 공유할 수 있다.

JobParameters

Job이 시작될 때 필요한 시작 조건을 JobParameters에 넣는다.

동일한 Job에 JobParameters까지 동일하면 같은 JobInstence이다.

Ex ) 편의점 리스트를 가져와서 저장하는 Job

• 밤 10시에는 C편의점 리스트의 정보 갱신
• 밤 11시에는 G편의점 리스트의 정보 갱신

조건 )

• 밤 10시에는 'JobParameter = C편의점'으로 구동되어야 함
• 밤 11시에는 'JobParameter = G편의점'으로 구동되어야 함

JobBuilderFactory를 가지고 올 수 없다면?

Spring Batch에서는 EnableBatchProcessing 어노테이션을 달면 아래 bean들을 사용할 수 있도록 미리 구현되어있다.

Spring Batch 프로젝트를 만들게 된다면 필수적으로 EnableBatchProcessing를 추가해 주어야 한다.

@EnableBatchProcessing를
@SpringBootApplication
public class Application {

    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }

}

EnableBatchProcessing으로 사용할 수 있게된 bean들

• JobRepository
• JobLuncher
• JobRegister
• JobExplorer
• PlatformTransactionManager
• JobBuilderFactory
• StepBuilderFactory

reference

Spring Batch란? 이해하고 사용하기

build.gradle

plugins {
    id 'org.springframework.boot' version '2.7.1'
    id 'io.spring.dependency-management' version '1.0.11.RELEASE'
    id 'java'
}

group = 'the.plural'
version = '0.0.1-SNAPSHOT'
sourceCompatibility = '11'

configurations {
    compileOnly {
        extendsFrom annotationProcessor
    }
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    implementation 'org.springframework.boot:spring-boot-starter-oauth2-client'
    implementation 'org.springframework.boot:spring-boot-starter-security'
    implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
    implementation 'org.springframework.boot:spring-boot-starter-validation'
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-websocket'
    implementation 'org.thymeleaf.extras:thymeleaf-extras-springsecurity5'
    implementation 'io.jsonwebtoken:jjwt:0.9.1'
    compileOnly 'org.projectlombok:lombok'
    runtimeOnly 'mysql:mysql-connector-java'
    annotationProcessor 'org.projectlombok:lombok'
    testImplementation 'org.springframework.boot:spring-boot-starter-test'
    testImplementation 'org.springframework.security:spring-security-test'
}

tasks.named('test') {
    useJUnitPlatform()
}

데이터베이스는 mysql을 사용하고 Jwt 토큰 기반 방식으로 로그인할 것이기 때문에 jwt 관련 설정을 추가해준다.

application.yml

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/데이터베이스 이름?serverTimezone=Asia/Seoul&characterEncoding=UTF-8
    username: 유저네임
    password: 비밀번호

  security:
    jwt:
      header: Authorization
      secret: c2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQtc2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQK
      token-validity-in-seconds: 86400

  jpa:
    database: mysql
    database-platform: org.hibernate.dialect.MySQL5InnoDBDialect
    generate-ddl: true
    hibernate:
      ddl-auto: update
    show_sql: true
    format_sql: true

#    default_batch_fetch_size: 1000

logging.level:
  org.hibernate.SQL: debug
  org.hibernate.type: trace
  # parameter Binding

회원가입

BaseTimeEntity

@Getter
@MappedSuperclass
@EntityListeners(AuditingEntityListener.class)
public class BaseTimeEntity {

    @CreatedDate
    private LocalDateTime createDate;

    @LastModifiedDate
    private LocalDateTime modifiedDate;
}

• createDate : 엔티티가 생성된 시간
• modifiedDate : 엔티티가 수정된 시간

엔티티의 생성시간과 수정시간 컬럼을 만들기 위해서 BaseTimeEntity 클래스를 생성한다.

Application

@EnableJpaAuditing // 이 부분
@SpringBootApplication
public class BerrApplication {

    public static void main(String[] args) {
        SpringApplication.run(BerrApplication.class, args);
    }

}

BaseTimeEntity를 만들었다면 꼭 Application에 @EnableJpaAuditing을 추가해줘야 한다.

Member

@Getter
@NoArgsConstructor(access = AccessLevel.PROTECTED)
@AllArgsConstructor
@Builder
@Entity
public class Member extends BaseTimeEntity {

    @Id @Column(name = "member_id")
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    @Column(length = 45, unique = true)
    private String email;

    @Column(length = 45)
    private String nickname;

    private int age;

    @Column(length = 100)
    private String password;

    @Enumerated(EnumType.STRING)
    private Role role;

    public void encodePassword(PasswordEncoder passwordEncoder){
        this.password = passwordEncoder.encode(password);
    }

로그인할 ID는 Email이다.

Role

public enum Role {
    USER, MANAGER, ADMIN;
}

enum 클래스인 것에 주의해서 설계하자

Repository

public interface MemberRepository extends JpaRepository<Member, Long> {

    Optional<Member> findByEmail(String email);
}

Extends는 JpaRepository<엔티티, 엔티티 PK 타입>이다. findByEmail은 JPA에서 지원하는 쿼리 메소드이며 이메일이 일치하는 Member를 찾아준다.

MemberSignUpRequestDto

@Data
@Builder
@AllArgsConstructor
public class MemberSignUpRequestDto {

    @NotBlank(message = "아이디를 입력해주세요")
    private String email;

    @NotBlank(message = "닉네임을 입력해주세요.")
    @Size(min=2, message = "닉네임이 너무 짧습니다.")
    private String nickname;

    @NotNull(message = "나이를 입력해주세요")
    @Range(min = 0, max = 150)
    private int age;

    @NotBlank(message = "비밀번호를 입력해주세요")
    @Pattern(regexp = "^(?=.*[A-Za-z])(?=.*\\d)(?=.*[@$!%*#?&])[A-Za-z\\d@$!%*#?&]{8,30}$",
            message = "비밀번호는 8~30 자리이면서 1개 이상의 알파벳, 숫자, 특수문자를 포함해야합니다.")
    private String password;

    private String checkedPassword;

    private Role role;

    @Builder
    public Member toEntity(){
        return Member.builder()
                .email(email)
                .nickname(nickname)
                .age(age)
                .password(password)
                .role(Role.USER)
                .build();
    }
}

서비스 계층은 인터페이스를 분리해서 만들어보자

MemberService

public interface MemberService {

    // 회원가입
    public Long signUp(MemberSignUpRequestDto requestDto) throws Exception;
}

MemberServiceImpl

@RequiredArgsConstructor
@Transactional(readOnly = true)
@Service
public class MemberServiceImpl implements MemberService {

    private final MemberRepository memberRepository;
    private final PasswordEncoder passwordEncoder;

    @Transactional
    @Override
    public Long signUp(MemberSignUpRequestDto requestDto) throws Exception {

        if (memberRepository.findByEmail(requestDto.getEmail()).isPresent()){
            throw new Exception("이미 존재하는 이메일입니다.");
        }

        if (!requestDto.getPassword().equals(requestDto.getCheckedPassword())){
            throw new Exception("비밀번호가 일치하지 않습니다.");
        }

        Member member = memberRepository.save(requestDto.toEntity());
        member.encodePassword(passwordEncoder);

        member.addUserAuthority();
        return member.getId();
    }
}

Exception 핸들러는 없다치고 Exception을 사용하겠다. Member에 미리 만들어 놓은 encodePassword 메서드를 사용해서 비밀번호를 암호화한다.

MemberController

@RequiredArgsConstructor
@RequestMapping("/member")
@RestController
public class MemberController {

    private final MemberService memberService;
    private final MemberRepository memberRepository;

    @PostMapping("/join")
    @ResponseStatus(HttpStatus.OK)
    public Long join(@Valid @RequestBody MemberSignUpRequestDto request) throws Exception {
        return memberService.signUp(request);
    }

이걸로 회원가입은 끝이났다. 로그인을 구현해보자.

로그인

로그인을 하기 위해서 SecurityConfig 클래스를 만들어 줍니다.

@Configuration
@RequiredArgsConstructor
public class SecurityConfig extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
                .formLogin().disable()
                .httpBasic().disable()
                .cors().disable()
                .csrf().disable()
                .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS)
                .and()
                .authorizeRequests()
                .antMatchers("/member/login").permitAll()
                .antMatchers("/member/join").permitAll()
                .antMatchers("/member").hasRole("USER")
                .anyRequest().authenticated();
    }

    @Bean
    public PasswordEncoder passwordEncoder(){
        return PasswordEncoderFactories.createDelegatingPasswordEncoder();
    }

    private static final String[] AUTH_WHITELIST = {
            "/v2/api-docs",
            "/v3/api-docs/**",
            "/configuration/ui",
            "/swagger-resources/**",
            "/configuration/security",
            "/swagger-ui.html",
            "/webjars/**",
            "/file/**",
            "/image/**",
            "/swagger/**",
            "/swagger-ui/**",
            "/h2/**"
    };

    // 정적인 파일 요청에 대해 무시
    @Override
    public void configure(WebSecurity web) throws Exception {
        web.ignoring().antMatchers(AUTH_WHITELIST);
    }
}

SecurityUtil

public class SecurityUtil {
    public static String getLoginUsername(){
        UserDetails user = (UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal();

        return user.getUsername();
    }
}

CustomUserDetailsService

@RequiredArgsConstructor
public class CustomUserDetailsService implements UserDetailsService {

    private final MemberRepository memberRepository;

    @Override
    public UserDetails loadUserByUsername(String username) throws UsernameNotFoundException {
        return memberRepository.findByEmail(username)
                .orElseThrow(() -> new UsernameNotFoundException("사용자를 찾을 수 없습니다."));
    }

}

JwtTokenProvider

@RequiredArgsConstructor
@Component
public class JwtTokenProvider {
    private String secretKey =
            "c2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQtc2lsdmVybmluZS10ZWNoLXNwcmluZy1ib290LWp3dC10dXRvcmlhbC1zZWNyZXQK";

    // 토큰 유효시간 168 시간(7일)
    private long tokenValidTime = 1440 * 60 * 7 * 1000L;
    private final UserDetailsService userDetailsService;

    // 객체 초기화, secretKey 를 Base64로 인코딩합니다.
    @PostConstruct
    protected void init() {
        secretKey = Base64.getEncoder().encodeToString(secretKey.getBytes());
    }

    // JWT 토큰 생성
    public String createToken(String userPk, List<String> roles) {
        Claims claims = Jwts.claims().setSubject(userPk); // JWT payload 에 저장되는 정보단위
        claims.put("roles", roles); // 정보는 key/value 쌍으로 저장됩니다.
        Date now = new Date();
        return Jwts.builder()
                .setClaims(claims) // 정보 저장
                .setIssuedAt(now) // 토큰 발행 시간 정보
                .setExpiration(new Date(now.getTime() + tokenValidTime)) // set Expire Time
                .signWith(SignatureAlgorithm.HS256, secretKey)  // 사용할 암호화 알고리즘
                // signature 에 들어갈 secret 값 세팅
                .compact();
    }

    // JWT 토큰에서 인증 정보 조회
    public Authentication getAuthentication(String token) {
        UserDetails userDetails = userDetailsService.loadUserByUsername(this.getUserPk(token));
        return new UsernamePasswordAuthenticationToken(userDetails, "", userDetails.getAuthorities());
    }

    // 토큰에서 회원 정보 추출
    public String getUserPk(String token) {
        return Jwts.parser().setSigningKey(secretKey).parseClaimsJws(token).getBody().getSubject();
    }

    // Request의 Header에서 token 값을 가져옵니다. "X-AUTH-TOKEN" : "TOKEN값'
    public String resolveToken(HttpServletRequest request) {
        return request.getHeader("X-AUTH-TOKEN");
    }

    // 토큰의 유효성 + 만료일자 확인
    public boolean validateToken(String jwtToken) {
        try {
            Jws<Claims> claims = Jwts.parser().setSigningKey(secretKey).parseClaimsJws(jwtToken);
            return !claims.getBody().getExpiration().before(new Date());
        } catch (Exception e) {
            return false;
        }
    }
}

JwtAuthenticationFilter

public class JwtAuthenticationFilter extends OncePerRequestFilter {

    private final JwtTokenProvider jwtAuthenticationProvider;

    public JwtAuthenticationFilter(JwtTokenProvider provider) {
        jwtAuthenticationProvider = provider;
    }

    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String token = jwtAuthenticationProvider.resolveToken(request);

        if (token != null && jwtAuthenticationProvider.validateToken(token)) {
            Authentication authentication = jwtAuthenticationProvider.getAuthentication(token);

            SecurityContextHolder.getContext().setAuthentication(authentication);
        }

        filterChain.doFilter(request, response);

    }
}

MemberService 추가

public String login(Map<String, String> members);

MemberServiceImpl 추가

@Override
public String login(Map<String, String> members) {

Member member = memberRepository.findByEmail(members.get("email"))
        .orElseThrow(() -> new IllegalArgumentException("가입되지 않은 Email 입니다."));

String password = members.get("password");
if (!member.checkPassword(passwordEncoder, password)) {
    throw new IllegalArgumentException("잘못된 비밀번호입니다.");
}

List<String> roles = new ArrayList<>();
roles.add(member.getRole().name());

return jwtTokenProvider.createToken(member.getUsername(), roles);

MemberController

@PostMapping("/login")
    public String login(@RequestBody Map<String, String> member) {
        return memberService.login(member);
    }

결과

Authentication, 모든 구현이 개체 Authentication목록을 저장하는 방법을 설명한다. GrantedAuthority는 본인에게 부여된 권한을 나타낸다.

개체는 GrantedAuthority 개체에 삽입되고 나중에 권한 부여 결정을 내릴때 둘 중 하나에 의해 읽힌다.

아래는 GrantedAuthority 하나의 메서드만 있는 인터페이스다.

String getAuthority();

이 방법을 사용하면 Authorizationmanager의 정확한String 표현을 얻을 수 있다.

Pre-Invocation Handling

Spring Security는 메소드 호출 또는 웹 요청과 같은 보안 객체에 대한 액세스를 제어하는 인터셉터를 제공한다.

The AuthorizationManager

AuthorizationManager AccessDecisionManager 및 AccessDecisionVoter을 모두 대체한다.

AccessDecisionManager를 사용 하도록 변경 하거나 사용자 지정하는 응용 프로그램이다.

AuthorizationManagers는 AuthorizationFilter에 의해 호출되며 최종 액세스 제어 결정을 내릴 책임이 있다.

AuthorizationManager 인터페이스에는 두 가지 메서드가 있다.

AuthorizationDecision check(Supplier<Authentication> authentication, Object secureObject);

default AuthorizationDecision verify(Supplier<Authentication> authentication, Object secureObject)
        throws AccessDeniedException {
}

위임 기반 AuthorizationManager 구현

사용자가 권한 부여의 모든 측면을 제어하기 위해 자신의 것을 구현할 수 있지만, Spring Security는 Authorizationmanager를 위임한다.

계층적 역할

계층적 역할이라는 것은 특정 역할이 다른 역할을 포함하는 것이다.

예를 들어서 USER, MANAGER, ADMIN 3개의 권한이 있다. (권한은 오름차순으로 높다.)

따라서 MANAGER는 USER의 권한을 가지고 있어야 하고, ADMIN은 USER, MANAGER 2개의 권한을 모두 다 가지고 있어야 한다.

이러한 계층적 역할을 지원하는 RoleVoter은 RoleHierarchyVoter로 구성되어 RoleHierarchy 사용자에게 할당된 모든 접근 가능한 권한을 얻는다.

@Bean
AccessDecisionVoter hierarchyVoter() {
    RoleHierarchy hierarchy = new RoleHierarchyImpl();
    hierarchy.setHierarchy("ROLE_ADMIN > ROLE_STAFF\n" +
            "ROLE_STAFF > ROLE_USER\n" +
            "ROLE_USER > ROLE_GUEST");
    return new RoleHierarchyVoter(hierarchy);
}

Authentication Mechanisms

1. 사용자 이름 및 비밀번호 - 사용자 이름/비밀번호로 인증하는 방법
2. OAuth 2.0 로그인 - OAuth 2.0 OpenID Connect 및 비표준 OAuth 2.0 로그인 (ex: 네이버 로그인, 카카오 로그인, 깃허브 로그인 ..)
3. SAML 2.0 로그인 : SAML 2.0 로그인
4. 중앙 인증 서버(CAS) : 중앙 인증 서버 지원
5. RememberMe : 세션 만료 후 사용자 정보를 기억함
6. JAAS 인증 : JAAS로 인증
7. OpenID : OpenID 인증(OpenID Connect와 혼동 X)
8. 사전 인증 시나리오 : SiteMinder 또는 Java EE 보안과 같은 외부 매커니즘으로 인증을 하지만 일반적인 악용에 대한 권한 부여 및 보호를 위해 여전히 Spring Security를 사용
9. X509 인증 : X509 인증

간단하게 스프링 시큐리티 내에서 폼 기반 로그인이 어떻게 작동하는지 살펴보자.

Form Login

Spring Security는 html 형식을 통해 제공되는 사용자 이름과 비밀번호에 대한 지원을 제공한다.

인증되지 않은 상태(로그인 X)에서 권한이 필요한 리소스에 접근하려고 할 때

1. 먼저 사용자가 권한이 없는 리소스 /private에 대해 인증되지 않은 요청을 한다.
2. Spring Security는 인증 FilterSecurityinterceptor되지 않은 요청이 AccessDeninedException에 의해서 ExceptionTranslationFilter로 반환된다.
3. 사용자가 인증되지 않았으므로 로그인 페이지로 리디렉션한다.
4. 브라우저는 리디렉션된 로그인 페이지를 요청한다.
5. 애플리케이션 내에서 로그인 페이지를 렌더링 한다.

로그인 페이지가 렌더링 되고 사용자가 사용자 이름과 암호를 제출하면 UsernamePasswordAuthenticationFilter로 인증한다.

로그인 과정

1. 사용자 이름과 암호를 추출하여 UsernamePasswordAuthenticationFilter를 거친다.
2. UsernamePasswordAuthenticationToken으로 전달된다.
3. 인증에 실패하면 Failure
   • SecurityContextHolder가 지워진다.
   • RememberMeServices.loginFail이 호출된다.
   • AuthenticationFailureHandler가 호출된다.
4. 인증에 성공하면 Success
   • SessionAuthenticationStrategy에서 새로운 로그인 알림을 받음
   • RememberMeServices.loginSuccess 호출
   • ApplicationEventPulbisher 발행
   • AuthenticationSuccessHandler 호출 일반적으로 이것은 로그인 페이지로 리디렉션할 때 SimpleUrlAuthenticationSuccessHandler 저장된 요청으로 리디렉션

참조의 인증, 권한 부여, 악용에 대한 보호를 사용할 때 아키텍쳐에 대한 높은 수준의 이해를 요구한다고 한다.

A Review of Filters

Spring Security의 Servlet 지원은 Servlet을 기반으로 하므로 Filter의 역할을 먼저 살펴보는 것이 도움이 된다.

아래의 Filter 그림은 단일 HTTP 요청에 대한 처리기의 일반적인 계층화를 보여준다.

클라이언트는 애플리케이션에 요청을 보내고 컨테이너는 FilterChain를 포함하고 요청 URI의 경로를 기반으로 처리한다.

DelegatingFilterProxy

Spring은 Servlet Filter와 DelegatingFilterProxy컨테이너의 라이프사이클과 Spring의 ApplicationContext를 지원한다.

DelegatingFilterProxy는 서블릿 컨테이너와 스프링 컨테이너(어플리케이션 컨텍스트) 사이의 링크를 제공하는 ServletFilter이다. 특정한 이름을 가진 스프링 빈을 찾아 그 빈에게 요청을 위임한다.

Why? 서블릿 필터(서블릿 컨테이너)와 시큐리티 필터(스프링 컨테이너)는 서로 다른 컨테이너에서 생성되고 동작하기 때문에 이를 연결해줄 것이 필요함

다음은 DelegatingFilterProxy의 동작 방식이다.

DelegatingFilterProxy에서 Bean Filter를 찾은 다음 ApplicationContext를 호출한다.

무슨말인지 잘 이해가 안될 수 있지만 아래 그림을 보면 이해가 좀 더 쉬울 것이다.

참고로 DispatcherServlet보다 DelegatingFilterProxy의 우선순위가 더 높다.

따라서 DispatcherServlet이 요청을 다 가로채갈일은 없다고 보면된다.

DelegatingFilterProxy 의사 코드

public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) {
    Filter delegate = getFilterBean(someBeanName);
    delegate.doFilter(request, response);
}

정리해서 DelegatingFilterProxy까지 적용된 요청의 동작 순서는 Request가 Filter(Servlet 컨테이너)를 거치다가 DelegatingFilterProxy를 만나면 ApplicationContext(Spring 컨테이너)로 이동해서 인증을 마저 진행한다.

사진으로 보면 다음과 같다.

FilterChainProxy

Spring Security의 Servlet 지원은 FilterChainProxy를 통해 많은 인스턴스에 위임할 수 있는 특수한 기능도 포함되어 있다.

Spring 컨테이너로 도착한 요청은 DelegatingFilterProxy로부터 요청을 위임 받고 실제로 보안을 처리한다.

사용자의 요청을 필터 순서대로 호출하여 전달한다. 사용자 정의 필터를 생성해서 기존의 필터 전후로 추가 가능하다.

마지막 필터까지 인증 및 인가 예외가 발생하지 않으면 보안을 통과한다.

SecurityFilterChain과 Security Filters

FilterChainProxy에서 잠깐 살펴 봤던것과 같이 마지막 필터까지 인증 및 인가 예외가 발생하지 않으면 보안을 통과한다.

스프링 시큐리티에서 제공하는 필터는 다음과 같다.

• ForceEagerSessionCreationFilter
• 채널 처리 필터
• WebAsyncManagerIntegrationFilter
• SecurityContextPersistenceFilter
• 헤더라이터 필터
• CorsFilter
• CSRF 필터
• 로그아웃 필터
• OAuth2AuthorizationRequestRedirectFilter
• Saml2WebSso 인증 요청 필터
• X509 인증 필터
• AbstractPreAuthenticatedProcessingFilter
• CasAuthenticationFilter
• OAuth2Login 인증 필터
• Saml2WebSso 인증 필터
• UsernamePasswordAuthenticationFilter
• OpenID인증 필터
• 기본 로그인 페이지 생성 필터
• 기본 로그아웃 페이지 생성 필터
• 동시 세션 필터
• DigestAuthenticationFilter
• BearerTokenAuthenticationFilter
• BasicAuthenticationFilter
• 요청 캐시 인식 필터
• SecurityContextHolderAwareRequestFilter
• JaasApiIntegrationFilter
• RememberMeAuthenticationFilter
• 익명 인증 필터
• OAuth2AuthorizationCodeGrantFilter
• 세션 관리 필터
• ExceptionTranslationFilter
• FilterSecurityInterceptor
• SwitchUserFilter

나 또한 스프링 시큐리티의 진입 장벽이 낮지 않다고 생각하고 단순히 구글링해서 클론코딩으로만 인증, 인가를 구현하는 것은 썩 좋지 않다고 생각한다.

때문에 이번 기회에 Spring Security docs를 읽어보면서 스프링 시큐리티의 동작원리, 인증, 인가 등등 자세히 알아보자.

Updating Dependencies

스프링 시큐리티를 사용하려면 Maven 또는 Gradle을 이용하여 종속성을 업데이트 하면 된다고 한다.

Maven

<dependencies>
    <!-- ... other dependency elements ... -->
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-security</artifactId>
    </dependency>
</dependencies>

Gradle

dependencies {
    compile "org.springframework.boot:spring-boot-starter-security"
}

의존성을 추가한 뒤 서버를 실행시키면 아래와 같은 화면이 나타난다.

Spring Boot Auto Configuration

Spring Boot는 자동으로 Spring Security의 기본 구성(서블릿 Filter와 springSecurityFilterChain)을 활성화한다.

Filter와 springSecurityFilterChain은 빈이며, 이는 응용 프로그램 내에 모든 보안(응용 프로그램 URL 보호, 사용자 이름 및 비밀번호 확인, 로그인 양식으로 리디렉션 등)을 담당한다고 한다.

Spring Boot는 많은 설정을 하지는 않지만 많은 작업을 수행할 수 있다.(Spring Security 덕분에)

기능요약은 다음과 같다.

• 응용 프로그램과의 모든 상호 작용을 위해 인증된 사용자 필요
• 기본 로그인 양식 생성
• 사용자 이름 user와 콘솔에서 제공하는 비밀번호를 사용하여 인증
• BCrypt를 사용해서 비밀번호를 암호화
• 로그아웃
• CSRF 공격 방지
• 세션 고정 보호
• 보안 헤더 통합
  • 보안 요청을 위한 HTTP Strict Transport Security
  • X-Content-type-Options 통합
  • 캐시 제어(나중에 애플리케이션에서 재정의하여 정적 리소스를 캐싱할 수 있음)
  • X-XSS-Protection 통합
  • 클릭재킹 방지를 위한 X-Frame-Options 통합

아래에서 자세하게 살펴보자

동시성과 병렬성

동시성이란 싱글 코어에서 멀티 쓰레드를 동작 시키는 방식이다. (코어의 종류에는 싱글 코어와 멀티 코어가 있다.)

• 싱글 코어 - 동시성
• 멀티 코어 - 병렬성

싱글 코어에서 멀티쓰레드를 동작 시키는 방식은 동시성, 멀티 코어에서 멀티쓰레드를 동작 시키는 방식은 병렬성이다.

따라서 이렇게 이해하면 좀 와닿을 수 있다.

동시성과 병렬성은 사전에서는 같은 의미로 사용하고 있지만, 컴퓨터 분야에서는 다르게 정의하고 있기 때문에 이 둘을 서로 비교해가며 알아보자

표로만 봐도 뭔가 다르다는게 느껴지긴 한다.

하지만 뭔가 잘 이해가 되지 않을 수도 있다. 동시에 실행되는 것도 아니고, 실행 되는 것 같아 보이는 것은 무슨 말인가;

아래의 그림을 통해 알아보자

Concurrent는 동시성이다.

그림과 같이 2개의 작업이 번갈아 가며 진행되면서 동시에 진행되는 것 처럼 보입니다. 그래서 동시에 실행되는 것 같아 보이는 것이라고 표현한다.

반면 Parrallel(병렬성)은 실제로 작업을 동시에 진행하는 것을 볼 수 있다.

실제로 4개의 코어를 가진 쿼드 코어의 속도는 이론적으로 실행 속도를 4배까지 향상시킬 수 있다.(물론 오버헤드로 인해 실제 4배가 되기는 어렵다.)

이렇게 동시성과 병렬성을 간단하게 알아보았다.

정리

• 병렬성이 멀티 코어 + 멀티 스레드 작업이라 항상 더 좋을 것 같지만, 동시성으로 접근하는게 좋은 경우도 있음 ex) 네트워크 통신, 파일 저장 및 로드 등의 I/O 작업은 CPU가 거의 일을 하지 않고 요청 후 응답이 올 때까지 대기상태에 있게됨. 이때 한 개의 CPU가 I/O 요청 후 기다리는 동안 다른 작업을 처리하도록 하면 효율적임

• 동시성과 병렬성을 혼용해서 처리하는 경우도 있음

• 동시성은 작업이 바뀔 때 문맥 교환이 발생하고, 동시 작업이 너무 많다면 문맥 교환의 오버헤드로 인해 싱글 코어에서 싱글 스레드로 작업하는 것이 더 빠를 수 있음

• 코어가 N배로 늘어나더라고 성능이 N배로 늘어나는 것은 아님(암달의 법칙) : 프로그램의 모든 부분을 Parallel 하게 작성할 수 없고 반드시 Sequential하게 동작해야 하는 부분들이 존재함

• https://mentha2.tistory.com/245
• https://seamless.tistory.com/42

스레드 풀이 무엇이고 자바에서 스레드 풀을 가지고 어떻게 스레드를 관리하는지 알아보자

Executor와 스레드 풀

자바 5는 자바 프로그래머가 태스크 제출과 실행을 분리할 수 있는 기능을 제공했다.

스레드의 문제 - 스레드 풀을 사용해야 하는 이유

자바 스레드는 직접 운영체제 스레드에 접근한다. 운영체제 스레드를 만들고 종료하려면 비싼 비용을 치러야 한다.

하지만 운영체제의 스레드 숫자는 제한되어있다. 운영체제가 지원하는 스레드 수를 초과해 사용하면 자바 애플리케이션이 예상치 못한 방식으로 크러시될 수 있으므로 기존 스레드가 실행되는 상태에서 계속 새로운 스레드를 만드는 상황이 일어나지 않도록 주의해야 한다.

🙄 스레드 풀이 뭔데?

위에서 스레드를 그냥 가져다 쓰면 무슨 일이 일어나는지 언급했다. 따라서 이 문제점들을 해결하기 위해서 스레드 풀을 사용해야 한다. (기본적으로 스프링 부트에서 제공하는 tomcat은 스레드 풀을 지원한다.)

자바 ExecutorService는 태스크를 제출하고 나중에 결과를 수집할 수 있는 인터페이스를 제공한다. 프로그램은 newFixedThreadPool같은 팩토리 메서드중 하나를 이용해 스레드 풀을 만들어 사용할 수 있다.

ExecutorService newFixedThreadPool(int nThreads)

위의 메서드는 워커 스레드라 불리는 nThreads를 포함하는 ExecutorService를 만들고 이들을 스레드 풀에 저장한다.

스레드 풀에서 사용하지 않은 스레드로 제출된 태스크를 먼저 온 순서대로 실행한다. 이들 태스크 실행이 종료되면 이들 스레드를 풀로 반환한다.

하지만 우리는 웹 백엔드 개발자가 아닌가 위에서 나온 JAVA 5에서 팩토리 메서드를 사용해가며 스레드 풀을 만들 필요 없다.

아래 코드처럼 yml에 서버의 스레드 풀을 직접 관리해도 좋고 당연한 소리지만 properties에서 관리해도 좋다.

server:
  tomcat:
    threads:
      max: 200 
      min-spare: 10 
    max-connections: 8192 
    accept-count: 100
    connection-timeout: 20000 
  port: 8080 

• max : 쓰레드의 최대 개수
• min-spare : 활성화 상태로 유지할 최소 쓰레드의 개수
• max-connections : 수립가능한 connection의 총 개수
• accept-count : 모든 스레드가 사용 중일때 들어오는 연결 요청 큐의 최대 길이
• connection-timeout : timeout 판단 기준 시간, 20초

위 내용이 무슨 뜻인지 아래에서 더 자세하게 살펴보자.

아래 사진은 스레드 풀에 스레드 200개가 있는 모습이다.

스레드 풀에 스레드가 없는데 계속 요청을 보내면 이미 스레드를 사용하고 있던 reqeust가 스레드를 반환해 줄 때까지 기다리거나, 거절하는 모습이다.

이 같은 모습은 request가 스레드를 사용하고 다시 스레드 풀로 반환해야 한다는 것을 의미한다.

스레드 풀의 특징은 다음과 같다

• 필요한 스레드를 스레드 풀에 보관하고 관리한다.
• 스레드 풀에 생성 가능한 스레드의 최대치를 관리한다.
• 톰캣은 최대 200개가 기본 설정이며 변경 가능하다.
• 스레드가 필요하면 이미 생성되어있는 스레드를 스레드 풀에서 꺼내 사용한다.
• 사용을 종료하면 스레드 풀에 해당 스레드를 반납한다.
• 최대 스레드가 모두 사용중이어서 스레드 풀에 스레드가 없다면 기다리는 요청은 거절하거나 특정 숫자만큼만 대기하도록 설정할 수 있다.

마지막 특징은 스레드 풀에 스레드가 0개이면 대기하는 request의 수를 정할 수 있다는 말이다.

스레드 풀의 궁극적인 장점은 하드웨어에 맞는 수의 태스크를 유지함과 동시에 수 천개의 태스크(request)를 스레드 풀에 아무 오버헤드 없이 제출할 수 있다는 점이다.

WAS의 주요 튜닝 포인트는 최대 스레드 수이다.

값을 너무 낮게 설정하면? 동시 요청이 많을 때 서버 리소스는 여유롭지만 클라이언트는 금방 응답이 지연된다.

값을 너무 높게 설정하면? 동시 요청이 많으면 CPU, 메모리 리소스 임계점 초과로 서버가 다운된다.

스레드 풀의 최적의 스레드 수를 고려하고 있다면 nGrider로 성능 테스트를 해보는 것을 추천한다.

references

• https://velog.io/@sihyung92/how-does-springboot-handle-multiple-requests

• https://jaehoney.tistory.com/155

• https://dolphinsarah.tistory.com/55?category=497941

REpresentational State Transfer

컴퓨터 시스템간의 상호 운영성을 제공하는 방법 중 하나이다.

WEB(1991)

"어떻게 인터넷에서 정보를 공유할 것인가?" (인터넷만 존재하는 시기)

가 기존 인터넷들의 문제점들 중 하나였다. 이에 대한 해답으로 WEB이 등장함 (월드 와이드 웹(WWW)이 팀 버너스-리에 의해 탄생)

"정보들을 하이퍼텍스트로 연결하자"

• 표현 형식 : HTML
• 식별자 : URI
• 전송 방법 : HTTP

위의 명세를 바탕으로 HTTP/1.0(1994~1996) 프로토콜을 개발하게 됨(기존에 사용하고 있던 HTTP에서 더욱 명세에 기능을 더하고 기존의 기능을 고친)

Roy T. Fielding(1994~1996)

"어떻게 하면 기존에 HTTP로 구축되어 있던 웹들과 호환성의 문제가 생기지 않게 개발할 수 있을까?"

HTTP Object Model(1994)

Roy T. Fielding이 제기했던 문제점들을 해결할 수 있는 방안

REST의 공식 발표(1998, 2000)

(1998) Roy T. Fielding이 Microsoft Research에서 HTTP Object Model을 REST이라는 이름으로 발표

(2000) 박사급 논문으로 발표

이 때 발표한 논문이 우리가 오늘날 알고 있는 REST를 정의하는 논문이다.

API

인터넷상에 API라는 것이 만들어지기 시작함

1998년에 마이크로소프트가 XML-RPC라는 원격으로 다른 시스템의 메서드를 호출할 수 있는 프로토콜을 만듦 -> SOAP

Salesforce API(2000) - SOAP 형태 - 매우 복잡하고 어려움

filckr(2004) - SOAP 형태 && REST 형태 - SOAP보다 매우 쉽고 간결해짐

사용자들이 생각한 SOAP와 REST의 차이점

결과

월드 와이드 웹(WWW)이 REST API로 정착하기 위해서

CMIS 등장(2008)

• CMS를 위한 표준
• EMC, IBM, Microsoft 등이 함께 작업
• REST 바인딩 지원

Roy T. Fielding : "CMIS에 REST는 존재하지 않는다."

Microsoft REST API Guidelines(2016)

마이크로소프트가 REST API에 대한 구체적인 가이드라인 제시

• URI는 https://{serviceRoot}/{collection}/{id} 형식이어야 한다.
• GET, PUT, DELETE, POST, HEAD, PATCH, OPTIONS를 지원해야 한다.
• API 버저닝은 Major.minor로 하고 URI에 버전 정보를 포함시켜야 한다.
• 쉽게 이해할 수 있도록 일관성을 지켜야한다.
• 기본 유형에 대한 JSON 형식의 기본 값은 RFC4627 규칙에 따라 JSON으로 직렬화되어야 한다.
• ....

Roy T. fielding : "이것은 REST API가 아니라, HTTP API라고 해야한다."

Roy T. fielding : "이런것들(CMIS, Microsoft REST API Guidelines)을 REST라고 부르려면 "hypertext-driven" 이어야 하며, REST API를 위한 최고의 버저닝 전략은 버저닝을 안 하는 것이다."

• hypertext : 컴퓨터나 다른 전자기기로 한 문서를 읽다가 다른 문서로 순식간에 이동해 읽을 수 있는 비선형적 구조 || 다른 문서와 쉽게 연결이 되도록 한 '링크'의 모음으로 구성된 문서

Roy T. fielding이 정의하는 REST API

REST 아키텍쳐 스타일을 따르는 API

REST : 분산 하이퍼미디어 시스템(ex: web)을 위한 아키텍쳐 스타일
아키텍쳐 스타일 : 제약 조건의 집합

아키텍쳐 스타일에 제시된 제약 조건들을 모두 따라야 REST API라고 부를 수 있음.

REST 아키텍쳐 스타일

• client-server
• stateless
• cache
• uniform interface
• layered system
• code-on-demand(optional)

위의 스타일 중 uniform interface를 제외한 5가지는 HTTP API로만으로 잘 지켜지지만 uniform interface에 대한 부분이 잘 지켜지지 않는다.

Uniform Interface의 제약 조건

• identification of resources - 리소스가 uri로 식별되야 함
• manipulation of resources through representations - representations을 통해서 자원을 조작해야 한다.
• self-descriptive messages - 스스로 설명하는 메시지가 되어야 한다.
• hypermedia as the engin of application state (HATEOAS) - 애플리케이션의 상태가 Hyperlink를 통해서 전이되어야 한다.

특히 self-descriptive messages와 HATEOAS가 안지켜진다.

Self-descriptive messages

Self-descriptive 하지 못하는 경우 - 1

API의 목적지가 어디인지 알 수 없음

Self-descriptive 하는 경우 - 1

Self-descriptive 하지 못하는 경우 - 2

어떠한 문법으로 작성된 API 인지 알 수 없음

Content-Type Header를 추가해서 작성한 문법을 알 수 있지만, "op"가 무엇이고, "path"가 무엇을 의미하는지 알 수 없다.

Self-descriptive 하는 경우 - 2

Media-Type(json-patch+json)을 추가해 줌으로써 이 Media-Type의 명세를 찾아서 "op", "path"가 의미하는 것을 알 수 있다.

HATEOAS

애플리케이션의 상태가 Hyperlink를 통해서 전이되어야 한다.

HATEOAS - 애플리케이션(게시판)

HTML을 통한 HATEOAS

왜 이걸 Uniform Interface ?

REST를 만들게 된 계기 : 어떻게 하면 기존에 HTTP로 구축되어 있던 웹들과 호환성의 문제가 생기지 않게 개발할 수 있을까?

• 서버와 클라이언트가 각각 독립적으로 진화
• 서버의 기능이 변경되어도 클라이언트를 업데이트할 필요가 없음

참고 : 클라이언트와 서버가 상호간 데이터를 주고 받는 형태의 아키텍쳐(REST)를 가지고 있기 때문에 서버와 클라이언트가 독립적으로 진화할 수 있다.

따라서 Uniform Interface가 반드시 만족되어야 REST API라고 부를 수 있음

REST가 잘 지켜지고 있는 예

• 웹 페이지를 변경했다고 해서 웹 브라우저를 업데이트할 필요는 없다.
• 웹 브라우저를 업데이트했다고 웹 페이지를 변경할 필요가 없다.
• HTTP 명세가 변경되어도 웹은 잘 동작한다.
• HTML 명세가 변경되어도 웹은 잘 동작한다.

따라서

그럼 API는 꼭 REST API를 사용해야 하는가?

Roy T. Fielding : 시스템 전체를 통제할 수 있거나, 진화에 관심이 없다면 REST에 대해 따지느라 시간을 낭비하지 마라

시스템 전체를 통제하는 경우

• 서버 개발자가 클라이언트 개발자를 마음대로 통제할 수 있는 경우
• 혼자 서버와 클라이언트를 다 만드는 경우

진화에 관심이 없는 경우

• 본인이 만든 서비스에 대한 평가를 잘 받아들이지 않는 경우(본인 판단)

우리가 만든 API는 이제 어떻게 불러야 할까?

1. REST API를 구현하고 REST API라고 부른다. - 제일 좋음
2. HTTP API라고 부른다.
3. REST API가 아니지만 REST API라고 부른다. - 현재 우리들의 상황

HTML과 JSON의 Self-descriptive와 HATEOAS

Self-descriptive와 HATEOAS가 독립적 진화에 어떻게 도움이 될까 ?

Self-descriptive - 확장 가능한 커뮤니케이션

서버나 클라이언트가 변경되더라도 오고가는 메시지는 언제나 self-descriptive 하므로 언제나 해석이 가능하다.

HATEOAS - 애플리케이션 상태 전이의 late binding

어디서 어디로 전이가 가능한지 미리 결정되지 않는다. 어떤 상태로 전이가 완료되고 나서야 그 다음 전이가 일어날 수 있는 상태가 된다. -> 링크는 동적으로 변경될 수 있다.

JSON이 Self-descriptive를 만족시키는 방법

방법 1 : Media-type 등록

1. 미디어 타입 정의 :

2. 미디어 타입 문서 작성 : "op"는 뭐고, "path"는 뭐다

3. IANA에 미디어 타입을 등록한다. - 이 때 만든 문서가 미디어 타입의 명세가 됨

4. 이제 application/json-patch+json 이라는 media-type을 보는 사람은 IANA에서 명세를 보고 해석할 수 있음

단점 : 매번 Media-Type을 IANA에 올려야 하기 때문에 매우 귀찮다.

방법 2 : Profile

1. "id"가 뭐고, "title"이 뭔지 의미를 정의한 명세를 작성한다.
2. Link 헤더에 profile relation으로 해당 명세를 링크한다.

단점 : 클라이언트가 Link 헤더와 profile을 이해해야하고, Content negotiation을 할 수 없다.

JSON이 HATEOS를 만족시키는 방법

방법 1 : data

data에 다양한 방법으로 하이퍼링크를 표현한다.

단점 : 링크를 표현하는 방법을 직접 정의해야한다.

방법 2 : HTTP 헤더 사용하기

Location 또는 Link를 사용하여 헤더로 링크를 표현한다.

정리

• 우리가 부르는 대부분의 "REST API"는 REST를 따르지 않고 있다.
• 특히 REST의 제약조건인 Self-descriptive와 HATEOAS를 잘 만족시키지 못한다.
• REST를 따르겠다면, Self-descriptivedhk와 HATEOAS를 만족시켜야 한다.
  • Self-descriptive : custom meadia-type이나 profile link relation 등으로 만족시킬 수 있다.
  • HATEOAS : HTTP 헤더나 본문에 Link를 담아 만족시킬 수 있다.
• REST API를 따르지 않겠다면, 뭐라고 부를지 결정해야 한다.

References

• 그런 REST API로 괜찮은가
• Architectural Styles and the Design of Network-based Software Architectures
• IANA
• REST API의 가이드라인
• hypertext-driven
• https://hanamon.kr/rest-api/
• https://meetup.toast.com/posts/92
• CMS

만약 자신이 상대방에게 정보를 전달하고 싶다면 위의 TCP/IP 4계층을 통해서 정보를 전달하게 됩니다.

자신이 다른 사람에게 메시지를 전달한다는 가정을 해보겠습니다.

1. 애플리케이션 계층에서 OS계층으로 정보를 넘깁니다. 메시지를 주고 받을 때는 주로 소켓 라이브러리를 사용합니다.

2. 애플리케이션 계층에서 받은 정보를 TCP 정보로 씌웁니다.

3. ** TCP 정보 위에 또 IP 정보를 씌웁니다.** -> IP 패킷이 생성됩니다.

4. LAN으로 정보가 나갈 때 이더넷 프레임을 통해서 나갑니다. 물리적인 정보가 포함됩니다.

TCP와 IP 패킷이 뭘까요 ?

저희는 메시지를 상대방에게 전송할 때 OS 계층에서 2단계(TCP, IP)나 정보를 씌우고 그걸 IP 패킷이라고 불렀습니다.

그렇다면 TCP와 IP 패킷이 뭘까요 ?

TCP (전송 제어 프로토콜)

TCP의 정보는 출발지 포트, 목적지 포트, 전송 제어와 관련된 정보, 순서와 관련된 정보, 검증과 관련된 정보 등등이 포함됩니다.

따라서 이러한 TCP 정보들이 자신이 보내고자 하는 정보를 1차적으로 포장합니다.

TCP의 3가지 특징

TCP는 3가지 특징을 가지고 있습니다.

• 연결지향 : 자신과 상대방이 연결이 되었는가 되지 않았는가
• 데이터 전달 보증 : 자신이 보낸 데이터가 잘 전달 되었는지 되지 않았는지 알 수 있음
• 순서 보장

3 Way Handshake - 연결 지향

TCP는 그 유명한 3 Way Handshake를 사용합니다. 뭐 굳이 해석하면 ...

네 .. 3 방향 악수라고 불리는 이유를 알아보겠습니다.

• SYN : 접속 요청
• ACK : 요청 수락

1. 우선 클라이언트인 Host A에서 서버에게 SYN이라는 요청을 보냅니다.
2. 요청을 받은 서버는 요청을 수락하면서 다시 클라이언트에게 요청을 합니다. (서버는 요청과 수락을 동시에 하는 셈)
3. 다시 요청을 받은 클라이언트는 서버가 보낸 요청을 수락하게 됩니다.

이렇게 3단계로 이루어진 과정을 마친 후 데이터를 전송합니다. (요즘은 3번째 단계와 함께 데이터를 보내기도 한다고 합니다.)

데이터 전달 보증

TCP 에서는 클라이언트가 서버에게 데이터를 전송하면, 서버는 다시 클라이언트에게 데이터를 잘 받았다고 response 해줍니다.

순서 보장

만약 데이터를 담은 패킷을 패킷 1, 패킷 2, 패킷 3과 같은 순서로 서버에게 전송했지만, 서버에 도착한 패킷 순서가 패킷 3, 패킷 2, 패킷 1 처럼 순서가 뒤바껴서 올 때 서버는 도착한 패킷을 다 버리고 클라이언트에게 패킷을 다시 요청합니다.

IP 패킷

TCP로 감싼 정보를 IP 정보를 한 번 더 감싸게 됨으로써 IP 패킷이 생성됩니다. IP 패킷은 출발지 IP, 목적지 IP 등등 전송 데이터를 가지고 있습니다.

그냥 IP도 아니고 IP 패킷이 무엇인지 궁금할 수 도 있는데, 그냥 이러한 정보들을 포장한 것이라고 보면 편할 것 같습니다. (ex: 택배 박스)

UDP (User Datagram Protocol)

사실 UDP는 TCP에 비해서 기능이 거의 없습니다. TCP가 지원하는 연결지향, 데이터 전달 보증, 순서 보장도 해주지 않습니다.

UDP는 IP와 거의 비슷하며, IP + Port 라고 생각하셔도 무방할 정도입니다.

그럼 UDP는 왜 써 ..?

UDP가 TCP보다 뛰어난 점이 딱 한가지 있습니다.

바로 속도가 TCP에 비해서 빠르다는 점인데 서비스가 너무 느려서 네트워크 쪽의 성능을 최적화 하고 싶다면 우선 TCP는 제외 해야합니다.

이미 요즘 인터넷 자체가 TCP를 채택하고 있고, 이미 구축되어 있는 것이 많기 때문에 전송 속도도 더 빠르게 하기 힘듭니다.

UDP는 아무 것도 없는 상태이기 때문에 UDP에 손을 대서 최적화를 해야합니다.

reference reference