2022.05.26 이론공부

1. 팝업과 모달창의 차이

팝업창 : 현재 열려있는 브라우저 페이지에 또 다른 브라우저 페이지를 띄우 것

     ㆍ웹 시작과 동시에 띄우는 경우가 많다

     ㆍ사용자 의도의 관점 : 현재 의도하는 목적과 상관없이 뜨는 창

     ㆍ자유도가 높다. ( 모달창은 부모창에 종속되어 모달창을 닫기 전에는 부모창 이벤트 조정 X )

 

모달창 : 기존의 브라우저 페이지 위에 새로운 원도우 창이 아닌 레이어를 까는 것

     ㆍ중간 중간 사용자에게 보여주는 경우가 많다

     ㆍ사용자 의도의 관점 : 다음 진행으로 넘어가기위한 필요에 의해 사용되는 창

     ㆍ반드시 노출해야하는 부분은 모달창 사용

---

2. GET과 POST의 차이

GET

- 리소스 조회

- 서버에 전달하고 싶은 데이터는 query(쿼리파라미터, 쿼리스트링)를 통해서 전달

- 메시지 바디를 사용해서 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많아서 권장 X

 

- GET요청은 캐시가 가능

- GET요청은 브라우저 히스토리에 남는다

- GET요청은 북마크 될 수 있다

- GET요청은 길이 제한이 있다

- GET요청은 중요한 정보를 다루면 안된다 (보안)

     ㆍ파라미터에 다 노출되기 때문에

- GET은 데이터를 요청할 때만 사용

 

POST

- 요청 데이터 처리

- 메시지 바디를 통해 서버로 요청 데이터 전달

- 서버는 요청 데이터를 처리 → 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행

- 주로 전달된 데이터로 신규 리소스 등록, 프로세스 처리에 사용

- 정리 : 이 리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리할지 리소스마다 정해야한다.

     1. 새 리소스 생성 (등록)

     2. 요청 데이터 처리

          ㆍ단순히 데이터를 생성하거나 변경하는 것을 넘어서 프로세스를 처리해야하는 경우

          ㆍPOST의 결과로 새로운 리소스가 생성되지 않을 수도 있음

          ㆍ예 ) POST /orders/{orderId}/start-delivery ( 컨트롤 URI )

     3. 다른 메서드로 처리하기 애매한 경우

          ㆍ예 ) 메시지 바디로 JSON으로 조회 데이터를 넘겨야 하는데, GET메서드를 사용하기 어려운 경우

 

- POST요청은 캐시되지 않는다

- POST요청은 브라우저 히스토리에 남지 않는다

- POST요청은 북마크 되지 않는다

- POST요청은 데이터 길이에 제한이 없다

 

차이점

1. 사용목적 : GET은 서버의 리소스에서 데이터 요청 / POST는 서버의 리소스를 새로 생성하거나 업데이트

2. 요청 body 유무 : GET은 없고 POST 존재

3. 멱등성 : GET은 멱등이며, POST 멱등이 아니다.

---

3. https ( HTTP Secure )

- HTTP protocol의 암호화된 버전

- 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer) 프로토콜을 이용하여 웹브라우저(클라이언트)와 서버가 데이터를 주고받은 통신 규약

- HTTPS는 http 메세지를 암호화하는 것

- HTTPS의 S는 Secure Socket, 보안 통신망을 말한다

- HTTPS의 암호화 원리의 핵심은 공개키 암호화 방식이다.

4. SSL ( Secure Sockets Layer )

- SSL과 TLS( Transport Layer Security )는 같은 뜻으로 말한다. 

- TLS는 클라이언트/서버 응용 프로그램이 네크워크로 통신을 하는 과정에서 도청, 간섭, 위조를 방지하기 위해 설계되었다. 그리고 암호화를 해서 최종단의 인증, 통신, 기밀성을 유지시켜준다.

- TLS라는 이름보단 SSL이라는 이름으로 더 많이 사용

 

SSL 인증서 정의

- SSL 인증서란 클라이언트와 서버간의 통신을 제 3자가 보증 해주는 문서이다

- 클라이언트가 서버에 접속시 서버는 클라이언트에게 인증서를 전달, 이 인증서로 신뢰성 확인

- 추가 참고 자료 : https://hyeonmin.tistory.com/87 의 3.tls handshake의 흐름을 보자!

 

SSL 장점

- 전달되는 내용이 다른 사람에게 노출되는 것을 막을 수 있다

- 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 알 수 있다

- 전달되는 내용을 악의적으로 변경되는 것을 막을 수 있다

 

SSL 암호화 종류

① 대칭키

- 대칭키 방식은 동일한 키로 암호화와 복호화를 할 수 있는 기법

- 암호화를 할때 사용하는 비밀번호를 키(key)라고 한다

- 단점

     ㆍ대칭키 유출 시 보안 X

 

② 공개키

- 공개 키는 공개키(public key)와 비밀키(private key, 개인키)가 있다

- 비밀키는 자신만 소지하고 공개키는 타인에게 제공

- 공개키로 암호화하면 비밀키로 복호화한다 / 비밀키로 암호화하면 공개키로 복호화한다

- 공개키는 공개되어 있으며 보통 디지털 인증서안에 포함되어 있다. 그렇기 때문에 공개키가 존재한다는 건 서버의 신원이 안전하다고 볼 수 있다. 우리는 이것을 전자서명이라고 부른다.

- 단점

     ㆍ공개키 암호화 방식의 알고리즘은 계산이 느리다

 

 

참고 자료 : https://goodgid.github.io/TLS-SSL/

---

5. web과 was의 차이

Web

- 웹 서버란 클라이언트(사용자)가 웹 브라우저에서 어떠한 페이지 요청을 하면 웹 서버에서 그 요청을 받아 정적 컨텐츠를 제공하는 서버

- 정적컨텐츠 : 단순HTML문서, CSS, JS, 이미지, 파일 등 즉시 응답 가능한 컨텐츠

- 웹 서버가 동적 컨텐츠를 요청 받으면 WAS에게 해당 요청을 넘겨주고, WAS에서 처리한 결과를 클라이언트에게 전달해주는 역할도 한다.

- 예 ) Apache

 

WAS ( Web Application Server )

- 사전적 정의 : 인터넷 상에서 HTTP 프로토콜을 통해 사용자 컴퓨터나 장치에 애플리케이션을 수행해주는 미들웨어로서, 주로 동적 서버 컨텐츠를 수행하는 것으로 웹서버와 구별이 되며, 주로 데이터베이스 서버와 같이 수행

- WAS는 웹 서버와 웹 컨테이너가 합쳐진 형태로서, 웹 서버 단독으로 처리할 수 없는 데이터베이스 조회나 다양한 로직 처리가 필요한 동적 컨텐츠를 제공한다.

- WAS는 JSP, Servelet 구동환경을 제공해주기 때문에 웹 컨테이너 혹은 서블릿 컨테이너라고 불린다

- 예 )  Tomcat

 

차이점

- 목적이 다르다

     ㆍ웹서버는 정적인 데이터를 처리하는 서버

             - 이미지나 단순 html파일과 같은 리소스를 제공하는 서버

     ㆍWAS는 동적인 데이터를 처리하는 서버

             - DB와 연결되어 데이터를 주고 받거나 프로그램으로 데이터 조작이 필요한 경우

 

WAS와 WebServer를 분리하는 경우

- 기능을 분리하여 서버의 부하방지

- 물리적으로 분리하여 보안강화

- 여러대의 WAS를 연결 가능 ( 로드밸런싱의 역할 및 fail over, fail back 처리에 유리 )

- 여러 웹 어플리케이션을 서비스 가능

 

---

6. 쿠키, 세션, 토큰 방식의 차이

Cookie

- 쿠키는 일종의 서버와 클라이언트가 대화하기 위한 수단

- 브라우저가 서버와 연결이 되었을 때 브라우저에서 자동적으로 쿠키를 생성하고, response할 때 쿠키를 담아서 보낸다

- 특정 호스트에서 생성된 쿠키는 이후 모든 요청마다 서버로 전송됨

- 요청 헤더의 set-cookie속성에 정보를 담을 수 있음

- 쿠키에 담긴 데이터는 브라우저에서 관리됨

- 이름, 값, 만료 날짜, 경로 정보로 구성

 

Session

- 서버와 클라이언트의 연결이 활성화된 상태

- 클라이언트가 서버와 통신을 시작하면 서버는 해당 클라이언트에 대해 유일한 값인 세션 id를 부여, 세션 스토리지에 세션 정보를 저장

- 클라이언트는 이 세션 id를 쿠키를 통해 기억

- 이후 클라이언트는 어떤 요청을 보낼 때마다 헤더의 cookie에 세션 id를 담아서 전송

- 서버는 클라이언트가 보낸 요청의 쿠키에 담긴 세션 id와 세션 스토리지에 담긴 세션 id를 대조해 인증 상태를 판단

   ( 즉, 세션과 쿠키는 완전히 분리된 개념이 아니며 세션은 쿠키를 기반으로 함 )

- 각 클라이언트마다 유니크한 세션 객체가 주어지고, 이 세션 객체에 데이터를 담아 관리

   ( 세션 객체가 자물쇠로 잠긴 상자라면 세션 id가 열쇠인 셈 )

- 세션을 사용하지 않고 쿠키만으로 어떤 데이터를 주고 받는다면, 클라이언트는 이미 모든 데이터를 알고 있다는 것

 

쿠키와 세션

- 사용자 경험을 제공 ( 로그인 유지 )

- 보안 유지 ( 인증 상태 관리 )

 

Token

- 인증을 위해 사용되는 암호화된 문자열

- 사용자가 인증에 성공하면 서버는 토큰을 생성해서 클라이언트로 보낸다

- 토큰도 세션과 마찬가지로 사용자가 보내는 요청에 포함이 됨

- 세션 인증에서는 서버가 세션 id를 저장하고 클라이언트가 쿠키에 실어 보낸 세션 id와 대조해서 확인하는 반면, 토큰을 사용하면 요청을 받은 서버는 토큰이 유효한지를 확인만 한다. http통신의 stateless한 성격과 더 적합한 인증 방식

- 세션 인증에 비해 서버 운영의 효율이 더 좋다