HTTP 프로토콜에 대해 설명
- HTTP(Hyper Text Transfer Protocol)이란 데이터를 주고 받기 위한 프로토콜이며, 서버/클라이언트 모델을 따릅니다.
- HTTP는 상태 정보를 저장하지 않는 Stateless의 특징과 클라이언트의 요청에 맞는 응답을 보낸 후 연결을 끊는 Connentionless의 특징을 가지고 있습니다.
- 장점
- 통신간의 연결 상태 처리나 상태 정보를 관리할 필요가 없어 서버 디자인이 간단하낟
- 각각의 HTTP 요청에 독립적으로 응답만 보내주면 OK
- 단점
- 이전 통신의 정보를 모르기 때문에 매번 인증을 해줘야 한다.
- 이를 해결하기 위해 쿠키(cookie)나 세션(session)을 사용해서 데이터 처리한다.
HTTP와 HTTPS의 차이점은 무엇인가요?
- HTTP는 평문 데이터를 전송하는 프로토콜이기 때문에, HTTP로 중요한 정보를 주고 받으면 제 3자에 의해 조회될수 있습니다.
이러한 문제를 해결하기 위해 HTTP에 암호화가 추가된 프로토콜이 HTTPS입니다. - HTTPS는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있습니다.
- SSL(Secure Socket Layer) 인터넷을 통해 전달되는 정보를 보호하기 위해 개발한 통신 규약
- HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신함으로써 암호화와 증명서, 안전성 보호를 이용할 수 있게 됩니다.
쿠키(Cookie)와 세션(Session)의 차이점에 대해 말하세요
- 쿠키는 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일입니다. HTTP에서 클라이언트의 상태 정보를 PC에 저장했다가 필요시 정보를 참조하거나 재사용할 수 있습니다.
- 세션은 일정 시간동안 같은 사용자로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술입니다.
즉, 방문자가 웹서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 합니다.
쿠키(Cookie) | 세션(Session) | |
저장 위치 | 클라이언트(=접속자PC) | 웹 서버 |
저장 형식 | text | Object |
만료 시점 | 쿠키 저장시 설정 (브라우저가 종료되도, 만료시점이 지나지 않으며 삭제되지 않음) |
브라우저 종료시 삭제 (기간 지정 가능) |
사용하는 자원(지소스) | 클라이언트 리소스 | 웹 서버 리소스 |
용량 제한 | 총 300개 하나의 도메인 당 20개 하나의 쿠키 당 4KB(=4096byte) |
서버가 허용하는 한 용량제항 없음 |
속도 | 세션보다 빠름 | 쿠키보다 느림 |
보안 | 세션보다 않좋음 | 쿠키보다 좋음 |
쿠키(Cookie)와 세션(Session)의 차이 (+캐시(Cache))
쿠키와 세션을 사용하는 이유?
- HTTP 프로토콜의 특징이자 약점을 보완하기 위해서 사용
HTTP 프로토콜의 특징
1. Connectionless 프로토콜 (비연결 지향)
- 클라이언트가 서버에 요청(Request)을 했을 때, 그 요청에 맞는 응답(Response)을 보낸 후 연결을 끊는 처리 방식
- HTTP 1.1 버전에서 커넥션을 계속 유지하고, 요청(Request)에 재활용하는 기능이 추가되었다. (HTTP Header)에 keep-alive 옵션을 주어 커넥션을 재활용하게 한다. HTTP 1.1 버전에서 디폴트(default) 옵션이다
- HTTP가 TCP 위에서 구현되었기 때문에(TCP : 연결 지향 ,UDP : 비연결 지향) 연결 지향적이라고 할 수 있다는 얘기가 있어 논란이 있지만, 아직까진 네트워크 관점에서 keep-alive는 옵션으로 두고, 서버 측에서 비연결 지향적인 특성으로 커넥션 관리에 대한 비용을 줄이는 것이 명확한 장점으로 보기 때누에 비연결 지향으로 알아두었다.
2. Stateless 프로토콜
- 커넥션을 끊는 순간 클라이언트와 서버의 통신이 끝나며 상태 정보는 유지하지 않는 특성이 있다
- 클라이언트와 첫 번째 통신에서 데이터를 주고 받았다 해도, 두 번째 통신에서 이전 데이터를 유지하지 않는다.
하지만, 실제로는 데이터 유지가 필요한 경우가 많다. - 정보가 유지되지 않으면, 매번 페이지를 이동할 때마다 로그인을 다시 하거나, 상품을 선택했는데 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 일이 발생 할 수 있다.
⇒따라서, Stateful 경우 대처하기 위해 쿠키와 세션을 사용한다. 쿠키와 세션의 차이점은 크게 상태 정보의 저장 위치이다. 쿠키는 '클라이언트(=로컬PC)'에 저장하고, 세션은 '서버'에 저장한다. - 서버와 클라이언트가 통신을 할 때 통신이 연속적으로 이어지지 않고 한 번 통신이 되면 끊어진다.
따라서 서버는 클라이언트가 누구인지 계속 인증을 해줘야 한다. 하지만 그것은 매우 귀찮고 번거로운 일이다.
그런 번거로움을 해결하는 방법은 바로 쿠키와 세션이다.
쿠키(Cookie)
- HTTP의 일종으로 사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.
- HTTP에서 클라이언트의 상태 정보를 클라이언트의 PC에 저장하였다가 필요시 정보를 참조하거나 재사용할 수 있다.
- 쿠키 특징
- 이름, 값, 만료일(저장 기간), 경로 정보로 구성되어 있다.
- 클라이언트에 총 300개의 쿠키 저장할 수 있다.
- 하나의 도메인 당 20개의 쿠키를 가질 수 있다.
- 하나의 쿠키는 4KB(=4096byte)까지 저장 가능하다.
- 쿠키의 동작 순서
- 클라이언트가 페이지를 요청한다.(사용자가 웹사이트에 접근)
- 웹 서버는 쿠키를 생성
- 생성한 쿠키에 정보를 담아 HTTP 화면을 돌려줄 때, 같이 클라이언트에게 돌려준다.
- 넘겨받은 쿠키는 클라이언트가 가지고 있다가(로컬PC에 저장) 다시 서버에 요청할 때 요청과 함께 쿠키를 전송한다.
- 동일 사이트 재방문 시 클라이언트의 PC에 해당 쿠키가 있는 경우, 요청 페이지와 함께 쿠키를 전송한다.
- 사용 예시
- 방문사이트에서 로그인 시, "아이디와 비밀번호를 저장하시겠습니까?"
- 팝업창을 통해 "오늘 이 창을 다시 보지 않기" 체크
세션(Session)
- 일정 시간 동안 같은 사용자(브라우저)로 부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다.
- 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.
즉, 방문자가 웹 서버에 접속해 있는 상태를 하나의 단위로 보고 그것을 세션이라고 한다. - 세션 특징
- 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
- 웹 서버의 저장되는 쿠키(=세션 쿠키)
- 브라우저를 닫거나, 서버에서 세션을 삭제했을 때문 삭제가 되므로, 쿠키 보다 비교적 보안이 좋다.
- 저장 데이터에 제한이 없다.(서버 용량이 허용하는 한에서)
- 각 클라이언트에 고유 SessionID를 부여한다. SessionID로 클라이언트를 구분해 각 요구에 맞는 서비스를 제공한다.
- 세션의 동작 순서
- 클라이언트가 페이지에 요청한다.
- 서버는 접근한 클라이언트의 Request-Header 필드의 Cookie를 확인하여, 클라이언트가 해당 session-id를 보냈는지 확인한다.
- session-id가 존재하지 않는다면 서버는 session-id를 생성해 클라이언트에게 넘겨준다.
- 클라이언트는 서버로부터 받은 session-id를 쿠키에 저장한다.
- 클라이언트는 서버에 요청시 이 쿠키의 session-id 값을 같이 서버에 전달한다.
- 서버는 전달받은 session-id로 session에 있는 클라이언트 정보를 가지고 요청을 처리 후 응답한다.
- 사용예시
- 화면을 이동해도 로그인이 풀리지 않고 로그아웃하기 전까지 유지
쿠키와 세션의 차이
- 쿠키와 세션은 비슷한 역할을 하며, 동작 원리도 비슷하다. 그 이유는 세션도 결국 쿠키를 사용하기 때문이다.
- 큰 차이점은 사용자의 정보가 저장되는 위치이다. 쿠키는 서버의 자원을 전혀 사용하지 않으면, 세션은 서버의 자원을 사용한다.
- 보안 면에서 세션이 더 우수하며
- 쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 우려가 있어서 보안에 취약하지만
- 세션은 쿠키를 이용해서 session-id만 저장하고 그것으로 구분하여 서버에서 처리하기 때문에 비교적 보안성이 높다.
- 라이프 사이클은 쿠키도 만료기간이 있지만 파일로 저장되기 때문에 브라우저를 종료해도 정보가 유지될 수 있다. 또한 만료기간을 따로 지정해 쿠키를 삭제할 때까지 유지할 수 있다.
- 반면에 세션도 만료기간을 정할 수 있지만, 브라우저가 종료되면 만료기간에 상관없이 삭제된다.
- 속도 면에서 쿠키가 더 우수하며,
- 쿠키는 쿠키에 정보가 있기 때문에 서버에 요청 시 속도가 빠르고
- 세션은 정보가 서버에 있기 때문에 처리가 요구되어 비교적 느린속도를 낸다.
- 보통 쿠기와 세션의 차이에 대해서 저장 위치와 보안에 대해서는 잘 알고 있지만, 사실 가장 중요한 것은 라이프사이클이다.
세션을 사용하면 좋은데 왜 쿠키를 사용할까?
- 세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기에 서버 자원에 한계가 있고, 속도가 느려질 수 있기 때문에 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있다.
쿠키와 세션 그리고 캐시(Cache)
- 캐시(Cache)는 웹 페이지 요소를 저장하기 위한 임시 저장소이고, 쿠키/세션은 정보를 저장하기 위해서 사용한다.
- 캐시는 웹페이지를 빠르게 렌더링 할 수 있도록 도와주고, 쿠키/세션은 사용자의 인증을 도와준다.
- 캐시는 이미지, 비디오, 오디오, css,js파일 등 데이터나 값을 미리 복사해 놓는 리소스 파일들의 임시 저장소이다.
- 캐시는 저장 공간이 작고 비용이 비싼 대신 빠른 성능을 제공한다.
- 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다.
- 이전에 사용된 데이터가 다시 사용될 가능성이 많으면 캐시 서버에 있는 데이터를 사용한다.
- 그래서 다시 사용될 확률이 있는 데이터들이 빠르게 접근할 수 있어진다.(페이지의 로딩 속도 상승)
- 캐시 히트(hit) : 캐시를 사용할 수 있는 경우 (ex. 이전에 왔던 요청이랑 같은 게 왔을 때)
- 캐시 미스(miss) : 캐시를 사용할 수 없는 경우 (ex. 웹서버로 처음 요청 했을 때)
www.naver.com 에 접속할 때 생기는 과정에 대해 설명해주세요.(웹 동작 방식 이해)
- 사용자가 브라우저에 URL(www.naver.com)을 입력
- DNS 서버에 도메인 네임으로 서버의 진짜 주소를 찾음
- IP 주소로 웹 서버에 TCP 3 handshake로 연결 수립
- 클라이언트는 웹 서버를 HTTP 요청 메시지를 보냄
- 웹 서버는 HTTP 응답 메시지를 보냄
- 도착한 HTTP 응답 메세지는 웹 페이지 데이터로 변환되고, 웹 브라우저에 의해 출력
TCP와 UDP의 차이를 설명
- TCP는 연결형 서비스로 3-way handshaking 과정을 통해 연결을 설정하기 때문에 높은 신뢰성을 보장하지만, 속도가 비교적 느리다는 단점이 있습니다.
- UDP는 비연결형 서비스로 3-way handshaking을 사용하지 않기 때문에 신뢰성이 떨어지는 단점이 있지만, 데이터 수신 여부를 확인하지 않기 때문에 속도가 빠르다는 장점이 있습니다.
- TCP는 신뢰성이 중요한 파일 교환과 같은 경우에 쓰이고 UUP는 실시간성이 중요한 스트리밍에 자주 사용됩니다.
프로토콜종료 | TCP | UDP |
연결 방식 | 연결형 서비스 | 비연결형 서비스 |
패킷 교환 방식 | 가상 회선 방식 | 데이터그램 방식 |
전송 순서 | 전송 순서 보장 | 전송 순서가 바뀔 수 있음 |
수신 여부 확인 | 수신 여부를 확인함 | 수신 여부를 확인하지 않음 |
통신 방식 | 1:1 통신 | 1:1 or 1:N or N:N 통식 |
신뢰성 | 높다 | 낮다 |
속도 | 느리다 | 빠르다 |
TCP 통신은 종료시에도 3 way-handshaking을 사용하나요?
- TCP는 3way-handshaking 과정을 통해 연결을 설정하고, 4 way-handshaking 과정을 통해 연결 해제합니다.
3 way-handshake 와 4 way-handshake를 설명
- 3 way- handshake란 TCP 네트워크에서 통신 하는 장치가 서로 연결이 잘 되었는지 확인하는 방법
송신자와 수신자는 총 3번에 걸쳐 데이터를 주고 받으면 통신이 가능한 상태인지 확인
- 4 way-handshake란 TCP 네트워크에서 통신 하는 장치의 연결을 해제하는 방법
송신자와 수신자는 총 4번에 걸쳐 데이터를 주고 받으면 연결을 끊습니다.
OSI 7 layer와 각 계층에 대해 설명
- 7 계층 (응용 계층) : 사용자에게 통신을 위한 서비스 제공. 인터페이스 역할
- 6 계층 (표현 계층) : 데이터의 형식(Format)을 정의하는 계층 (코드 간의 번역을 담당)
- 5 계층 (세션 계층) : 컴퓨터끼리 통신을 하기 위해 세션을 만드는 계층
- 4 계층 (전송 계층) : 최종 수신 프로세스로 데이터의 전송을 담당하는 계층 (단위 :Segmetn) (ex. TCP, UDP)
- 3 계층 (네트워크 계층) : 패킷을 목적지까지 가장 빠른 길로 전송하기 위한 계층 (단위 : Packet) (ex. Router)
- 2 계층 (데이터링크 계층) : 데이터의 물리적인 전송과 에러 검출, 흐름 제어를 담당하는 계층(단위 : frame) (ex. 이더넷)
- 1 계층 (물리 계층) : 데이터를 전기 신호로 바꾸어주는 계층 (단위 : bit) (장비 : 케이블, 리피터, 허브)
HTTP Method와 각각이 사용되는 경우에 대해서 설명
- HTTP 메소드는 클라이언트가 서버에게 사용자 요청의 목적을 알리는 '수단'
종료 | 기능 |
GET | 데이터 조회 |
POST | 요청 데이터 처리 (보통 데이터 등록 사용) |
PUT | 데이터 변경 (해당 데이터가 없으면 생성) |
PATCH | 일부 데이터만 변경 |
DELETE | 데이터 삭제 |
GET과 POST의 차이에 대해 설명
- GET은 데이터를 조회하기 위해 사용되는 방식으로 데이터를 헤더에 추가하여 전송하는 방식입니다.
URL에 데이터가 노출되므로 보안적으로 중요한 데이터를 포함해서는 안됩니다. - POST는 데이터를 추가 또는 수정하기 위해 사용되는 방식으로 데이터를 바디에 추가하여 전송하는 방식입니다.
완전히 안전하다는 것은 아니지만 URL에 데이터가 노출되지않아 GET보다 안전합니다.
처리 방식 | GET 방식 | POST 방식 |
URL에 데이터 노출 여부 | O | X |
URL 예시 | http://localhost:8080/boardList?name=제목&contents=내용 | http://localhost:8080/addBoard |
데이터의 위치 | Header(헤더) | Body(바디) |
캐싱 가능 여부 | O | X |
멱등성 여부 | O | X |
세션 기반 인증과 토큰 기반 인증의 차이에 대해 설명
- 세션 기반 인증은 클라이언트로 부터 요청을 받으면 클라이언트의 상태 정보를 저장하므로 Stateful한 구조를 가지고
- 토큰 기반 인증은 상태 정보를 서버에 저장하지 않으므로 Stateless한 구조를 가집니다.
Stateful한 세션 기반의 인증 방식을 사용하게 된다면 어떠한 단점이 있을까요?
- 서버에 세션을 저장하기 때문에 사용자가 증가하면 서버에 과부하를 줄 수 있어 확장성이 낮습니다.
- 해커가 훔친 쿠키를 이용해 요청을 보내면 서버는 올바른 사용자가 보낸 요청인지 알 수 없습니다.(세션 하이재킹 공격)
세션 기반 인증과 토큰 기반 인증은 각각 어느 경우에 적합한가요?
- 단일 도메인이라면 세션 기반 인증을 사용하고, 아니라면 토큰 기반 인증을 사용하는 것이 적합하다고 생각합니다.
- Why? - 세션을 관리할 때 사용되는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 있기 때문에 여러 도메인에서 관리 하는 것은 어렵습니다.(CORS문제)
JWT 토큰에 대해 설명
- JWT는 JSON포맷을 이용하는 Claim 기반의 웹 토근이며, 토큰 자체를 정보로 사용하는 Self-Contained 방식으로 정보를 안전하게 전달합니다.
- JWT는 헤더(Header).내용(Payload).서명(Signature)로 구성되며 각 파트를 점(.)으로 구분
- 헤더 (Header) : 토큰의 타입과 해시 암호화 알고리즘(방식지정)으로 이루어져 있다.
- 내용 (Payload) : 토큰에 사용자가 담고자 하는 정보를 담는다. 내용에는 Claim이 담겨있고 ,JSON(Key/Value) 형태의 한 쌍으로 이루어져 있다.
- 서명 (Signature) : 토크을 인코딩하거나 유효성 검증할 때 사용하는 고유한 암호화 코드이다. 헤더와 내용의 값을 인코딩한다.
대칭키, 비대칭키 암호화 방식에 대해 설명
- 대칭키와 비대칭키는 양방향 암호화 방식
대칭키
- 암호화와 복호화에 같은 암호 키를 쓰는 알고리즘
- 중간에 누군가 암호 키를 가로채면 암호화된 정보가 유출될 수 있다는 단점
- 이런 문제를 보완한 새로운 방식이 비대칭키(공개키) 입니다.
비대칭키
- 암호화와 복호화할 때 키를 서로 다른 키로 사용하는 암호화 알고리즘
- 타인에게 절대 노출되어서는 안되는 개인키(private key)와 공개적으로 개방되는 있는 공개키(public key)를 쌍으로 이룬 형태
Connection Timeout과 Read Timeout의 차이에 대해 설명
- 서버 자체에 클라이언트가 어떤 사유로 접근을 실패했을 시 적용되는 것이 Connection Timeout 입니다.
즉, 접근을 시도하는 시간 제한이 Connection Timeout 되는 것을 말합니다. - 클라이언트가 서버에 접속을 성공 했으나 서버가 로직을 수행하는 시간이 너무 길어 제대로 응답을 못 준 상태에서 클라이언트가 연결을 해제하는 것이 Read Timeout입니다.
이 경우는 클라이언트는 해당 상황을 오류로 인지하고, 서버는 계속 로직을 수행하고 있어 성공으로 인지해 양 사이드간 싱크가 맞지 않아 문제가 발생할 확률이 높습니다.
공인(public)IP 와 사설(private) IP의 차이에 대해 설명
- 공인IP는 ISP(인터넷 서비스 공급자)가 제공하는 IP 주소이며, 외부에 공개되어 있는 IP주소 입니다.
- 사설IP는 일반 가정이나 회사 내 등에 할당한 네트워크 IP 주소이며, IPv4의 주소부족으로 인해 서브넷팅된 IP이기 때문에 라우터(공유기)에 의해 로컬 네트워크상의 PC나 장치에 할당됩니다.
- 사설IP 주소만으로는 인터넷에 직접 연결할 수 없고, 라우터를 통해 1개의 공인IP을 할당하고, 라우터에 연결된 개인PC는 사설IP를 각각 할당 받아 인터넷에 접속 할 수 있습니다.
출처
https://dev-coco.tistory.com/161
'이론 > ⭐' 카테고리의 다른 글
개발자 기술면접 질문 정리 - 운영체제 (1) | 2024.09.03 |
---|---|
개발자 기술면접 질문 정리 - 알고리즘 (0) | 2024.09.03 |
기술면접 질문 정리 - 자료구조 (6) | 2024.09.03 |
기술면접 질문 정리 - 백엔드 (2) | 2024.09.01 |
기술면접 질문 정리 - 데이터베이스 (2) | 2024.09.01 |