[6주차] 멘토링 키워드

주절주절,, 자바의 신 책을 다 읽고(다 읽었다고 했지만 꼼꼼히 한 번 더 봐야할 것 같다) 드디어 JSP책으로 넘어갔다. 괜히 새 책이라 그런가 새학기 들어가서 새로운 과목을 처음 배울때처럼 설레고 흥미로웠다. JSP책 관련 질문은 JSP의 기본동작 원리와 쿠키 세션에 대한 내용이 주를 이루었다. 멘토링을 진행하고 난 뒤 다음날 중복 로그인 문제로 세션관련 코드를 보게되었는데 괜히 책에서 읽었던 내용 보게되서 괜히 반가웠다 ㅎㅎ 아무튼 오늘도 멘토님께서 언급해주신 키워드를 하나씩 알아보자!

 

 📝Restful API 

REST 란 웹(HTTP)의 장점을 최대한 활용할 수 있는 아키텍쳐이다. REST API(REpresentational State Transfer)는 REST 아키텍쳐 스타일을 따르는 API로, 웹상에서 사용되는 여러 리소스를 HTTP URI(Resourse)로 표현하고, 해당 리소스에 대한 행위를 HTTP Method( GET, POST, PUT, PATCH, DELETE )로 정의하여 특정한 형태(자원의 형태)로 전달하는 방식을 말한다. REST API 설계 가이드를 따라 API를 만들어 웹서비스를 제공하면 해당 웹 서비스는 RESTful하다고 말한다. REST API는 아래와 같은 특징을 가진다. 

 

• Uniform (유니폼 인터페이스) : 유니폼 인터페이스는 URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍쳐 스타일을 의미한다.
• Stateless (무상태성) : 작업을 위한 상태정보를 따로 저장하거나 관리하지 않는 특징을 가진다. 즉, 세션 및 쿠키같은 정보를 저장하지 않기 때문에 API 서버는 들어오는 요청을 처리만 하면 된다. 따라서 서비스의 자유도가 높아지고 서버가 불필요한 내용들을 관리하지 않음으로써 비용이 줄어든다.
• Cacheable (캐싱) : HTTP라는 기존 웹표준을 그대로 사용하기에, 웹에서 사용하는 기존 인프라를 사용 할 수 있고 결국 HTTP가 가진 캐싱 기능을 사용 할 수 있다.
• Self-descriptiveness (자체 표현 구조) : JSON형태의 메시지를 통해 내용을 직관적으로 이해할 수 있다. 즉, REST API 메시지 구조만을 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어있다.
• Server / Client 구조 : REST 서버는 API를 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보) 등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되기 때문에 서버/클라이언트간 개발해야 할 내용이 명확하며 서로간의 의존성이 줄어들게 된다.
• 계층형 구조 : REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 프록시, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.

 

 📝java 8 

- Lambda

- Stream

- Optional

- java.time

 

📝HTTP 

 - 주요 특징

HTTP 프로토콜은 connectionless(비연결성) 방식으로 작동한다. 이는 서버에 연결을 요청하고, 요청한 건에 대해 응답을 받으면 연결을 끊어버리는 것을 말한다. 이러한 특징으로 인해 서버는 클라이언트를 기억하고 있지 않으며 이를 stateless(상태를 가지고 있지 않음) 라고 한다. 즉, HTTP의 stateless 특징은 Connctionless에서 파생되어 나온 특징이라고 볼 수 있다. 이러한 stateless의 특징으로 인해 번거로움이 발생한다. 예를들면, 사용자가 쇼핑몰에 로그인을 한 뒤 상품을 클릭하게 되면 로그인을 한 상태를 기억하고 있지 않기 때문에 또 다시 로그인을 해야하는 경우가 발생한다. 그리고 결제창으로 넘어갈 때 역시 또 다시 로그인을 해야한다. 이러한 문제를 해결하고자 쿠키와 세션이 등장을 하게 된다. 쿠키는 브라우저 단에서, 세션은 서버단에서 클라이언트의 정보를 저장하여 서버가 클라이언트의 상태를 확인하여 그에 맞는 동작을 할 수 있게끔 한다.  

 

 - keep-alive

위에서 언급했듯이 HTTP 프로토콜은 connectionless(비연결성) 특징을 가지고 있어 요청이 있을 때마다 연결(3way-handshake)/해제(3way-handshake) 의 과정을 거치게 된다. 이는 연결(3way-handshake)/해제(3way-handshake)에 대한 오버헤드가 발생하게 된다는 단점이 있다. 그래서 이런 커넥션을 연결/해제하는데 발생하는 오버헤드를 없애기 위해 이미 연결되어 있는TCP 커넥션을 재사용하는 지속 커넥션이 HTTP 1.1부터 등장을 하게 되었다. header의 Connection속성에 Keep-Alive를 명시해주면 지정된 시간동안 연결을 끊지 않고 요청을 계속 보낼 수 있으며 이는 TCP 연결의 handshake 과정을 거치지 않기 때문에 성능적인 측면에서 향상된 모습을 볼 수 있다.

 

📝쿠키 보안 설정 방법 

쿠키의 보안 설정 방법에 대해서 알아보기 전에 쿠키가 무엇인지 먼저 살펴보자. 

 

HTTP 쿠키란? stateless(상태가 없는)인 HTTP 프로토콜에서 웹 브라우저와 웹서버 통신 시 사용자의 정보 또는 상태를 기억시키기 위해서 response header에 붙여 사용자에게 전송하는 데이터이다. 쿠키를 생성하면 사용자 PC 에 저장이 되며, 동일한 브라우저에서 요청을 전송할 때마다 쿠키의 정보를 요청 헤더에 붙여 웹 서버에 전달한다.

 

하지만 쿠키는 사용자의 PC에 저장된다는 점에서 공용 PC일 경우 사용자의 정보가 노출될 가능성이 크다. 또한, Javascript의 document.cookie라는 명령어를 통해서 쿠키의 값을 알아낼 수 있다는 점에서 보안에 취약하다(XSS 공격). 이를 해결하기 위한 보안 설정방법은 크게 두가지가 존재한다. 

 

1. HttpOnly

서버에서 set-Cookie 의 응답 헤더에 HttpOnly를 추가하게 되면 사용자가 접속한 웹 브라우저에서 스크립트로 쿠키에 접근하는 것을 막을 수 있다. 

 

2. Secure

secure설정 역시 set-Cookie 의 응답 헤더에 설정해준다. 이 설정은 사용자가 접속한 웹 브라우저에서 HTTPS 통신일 때만 쿠키를 전송하는 방식이다. 즉, 평문으로 쿠키를 전송하지 않기 때문에 기밀성이 보장되는 방법이다. 

 

 

참조

https://developer.mozilla.org/ko/docs/Web/HTTP/Cookies

https://coyagi.tistory.com/entry/%EC%8B%9C%ED%81%90%EC%96%B4%EC%BD%94%EB%94%A9-%EC%BF%A0%ED%82%A4-%EB%B0%8F-%EC%84%B8%EC%85%98%EA%B4%80%EB%A6%AC

https://crossjin.tistory.com/entry/HTTP-%EC%BF%A0%ED%82%A4%EC%9D%98-%EB%B3%B4%EC%95%88-%EC%84%A4%EC%A0%95-%EB%B0%A9%EB%B2%95-HTTP-%EC%9A%94%EC%B2%AD-%EB%A9%94%EC%86%8C%EB%93%9C-%EC%A2%85%EB%A5%98

https://velog.io/@kjh107704/REST-%EC%84%9C%EB%B2%84-REST-API%EB%9E%80

https://mangkyu.tistory.com/46