[기술면접 대비] Web 일반 & 보안

HTTP

👉 HTTP 란? 

Hyper Text Transfer Protocol로 클라이언트와 서버 간에 정보를 주고 받는 프로토콜 (규약)

• HTTP Request 메시지 = Request Header + Request Body
• HTTP Response 메시지 = Response Header + Response Body

 

👉 HTTP Header 

HTTP 메시지에 대한 정보를 포함하며, key-value 형태

• content-type : 본문의 Type을 나타냄. ex) application/json, text/html
• Accept : 클라이언트가 처리 가능한 Type을 나타냄 ex) application/json, text/html 등

 

👉 HTTP 의 주요 특징

• 비연결 (서버-클라 전송 완료시 연결 종료, Connectionless),
• 무상태 (연결 종료시 상대방에 대한 상태 정보 유지 x, Stateless)
• HTTP는 텍스트, 이미지,영상, JSON 등의 거의 모든 형태의 데이터를 전송 가능

 

👉 HTTP 의 Stateless, Connectionless 특징으로 인해 발생하는 현상 (쿠키, 세션 사용 전)

실제 웹 서비스에서는 데이터 유지가 필요한 경우가 많으며, 데이터 유지를 위해 쿠키와 세션, 토큰 개념을 사용

 

만약 데이터(유저 정보)가 페이지 이동마다 유지되지 않으면 다음과 같은 현상 발생

• 페이지 이동할 때마다 로그인을 다시 해야됨
• 상품을 선택했는데, 구매 페이지에 선택한 상품이 없음

 

👉 HTTP 를 생성하는 도구 (API Test 어떤 것 사용)

curl, postman, wget, httpi 등

 

👉 HTTP 동작 과정

(1) 클라이언트 URL 주소 입력 및 DNS 서버를 통해 IP 얻어옴

(2) 웹 서버와 TCP 연결 시도 (3-way handshaking)를 통한 소켓 개방

(3) 클라이언트가 서버에게 요청 (Request)

(4) 서버가 클라이언트에게 응답 (Response)

(5) 연결 종료 (4-way handshaking)

(6) 클라이언트는 응답 기반 웹 문서 출력

 

👉 HTTP/1.0 => HTTP 1.1 특징은?

• TCP 세션을 지속적으로 유지할 수 있는지에 대한 차이 (keep-alive 지원 통한 persistent connection 구현)
• 한 사용자가 반복 요청시 TCP Handshake 를 매번 했었는데, keep-alive는 연결을 유지해 hand-shake를 하지 않음

 

👉 HTTP/1.1의 문제점은?

• 1.1의 HOL Blokcing (Head of line blocking) 문제로, 요청(Line)의 앞부분(head)에서 지연 발생시(ex. 패킷 크기가 너무 큼) 성능 저하 발생하는 문제 ex) 이미지 + css + xml 파일 전송시 이미지가 너무 커서 오래걸림
• 1.1은 헤더에 많은 메타 데이터가 들어가 있어 무거움
• 1.1은 다중 Connections을 활용한 병렬 처리

 

👉 HTTP/2.0 특징은?

• 멀티플렉싱, 헤더 압축, 서버 푸시 등을 지원하여 1.1의 문제 해결
• 멀티플렉싱 : 여러 개의 스트림을 사용하여 프레임을 조각냈다가 합치면서 병렬 송수신
• 헤더 압축 : 허프만 코딩 압축 알고리즘 사용하여 HPACK 압축 형식 사용
• 서버 푸시 : HTML 파일 수신후 CSS 파일 요청해야 CSS파일 수신 하는 것이 아닌 자동 CSS파일도 같이 수신함
• 2.0은 다중 Connections에서 프레임을 나누어 섞어 보내고 재조합 하므로, Connections 자체가 병렬 송수신 

 

👉 HTTP/3.0 특징은?

• 전송 속도 향상 : TCP 기반 대신 UDP 기반으로 돌아가며 QUIC 계층위에서 돌아감 
• 멀티플렉싱 기능과 초기 연결 설정시 지연시간 감소 장점이 있음 (TCP를 사용하지 않아 3-WAY Handshake 필요 X)
• TCP와 TLS를 이용한 HTTPS 방법의 2.0과 달리 QUIC를 이용한 HTTPS 방법을 통해 초기 연결 시간 단축

 

HTTP & HTTPS

👉 HTTPS 란?

보안이 강화된 버전의 HTTP 프로토콜 (HTTP over TLS(Transport Layer Security) / HTTP over SSL(Secure Socket Layer)  / HTTP Secure)로 주로 443번 활용하고, 전송 간 SSL이나 TLS를 통해 모든 세션 데이터를 암호화함.

 

👉 HTTPS 의 원리

공개키 알고리즘 방식으로 서버는 공개키를 가지고, 클라이언트가 개인키를 가지고 전송 받은 데이터 복호화

 

👉 HTTPS 장단점

장점 : 보안성(모든 통신 내용이 암호화), 중간에 정보를 가로챌 우려가 적어 안전

단점 : 인증서 유지 비용, 암호화 과정이 웹서버에 부하를 줌

 

👉 HTTPS (SSL) 동작 과정

(1) 클라이언트 URL 주소 입력 및 DNS 서버를 통해 IP 얻어옴

(2) 웹 서버와 TCP 연결 시도 (3-way handshaking)를 통한 소켓 개방

(3) Handshaking 과정에서 SSL 인증서 확인

(4) 서버와 클라이언트는 Session Key (서버 생성)를 활용해 데이터 암복호화 요청 (Reqeust) / 응답 (Response)

(5) 클라이언트가 서버에게 요청 (Request)

(6) 서버가 클라이언트에게 응답 (Response)

(7) 연결 종료 (4-way handshaking) 및 session key 폐기 

(8) 클라이언트는 응답 기반 웹 문서 출력

 

👉 HTTPS 사용 이유

HTTP 전송가 중간에 탈취(Snipping) 당할 수 있으니까, 서버에서 CA를 통해 인증서를 만들어서 클라이언트에게 보내면 HTTPS로 접근할 때 보내는 데이터가 암호화되서 들어오게 함

 

👉 HTTP vs HTTPS  차이는

HTTP : 서버와 클라이언트간에 데이터를 주고 받는 프로토콜, 단방향 통신
HTTPS : HTTP 프로토콜에 보안 요소(SSL 인증서)를 활용. 데이터를 공개키 암호화 방식으로 암호화하여 통신

 

Socket, WebSocket, 실시간 통신

👉 Socket 이란?

소켓은 ip주소와 포트번호를 가진 인터페이스 (리눅스에서  소켓은 내부적으로 파일로 다루어지며 (.sock) 프로세스는 이 소켓을 사용할때 파일디스크립터를 통해 사용)

 

👉 Socket과 WebSocket 차이

Socket

• IP와 Port 번호를 활용하는 TCP/IP 기반의 데이터 통신 창구
• bind-listen-accept-send,receive, 3-way-handshaking 등 사용

 

WebSocket

• 실시간 네트워킹 : 웹 환경에서 연속된 데이터 빠르게 노출하기 위한 Socket 통신 (채팅, 비디오 등)
• 양방향 통신 : 데이터 송/수신 동시 처리, 클라-서버간 원할 때 데이터 주고 받음
• Handshaking 진행 : WebSocket은 Http Header를 통한 Handsahking을 진행 후, 통과시 WebSocket Protocol 통신
• Header 중 Upgrade 필드 - Websocket으로 변환, UTF-8형식의 Encoding 된 데이터만 사용
• Pooling 방식 (HTTP 기반 구현 방식) 보다 주고 받는 데이터 양이 작아 (Handshaking 후에 순수 메시지 크기만 부담) 네트워크 오버헤드가 적음

 

👉 실시간 통신 방법 비교 (Pooling, Long Pooling, Streaming vs WebSocket)

WebSocket 등장 이전엔 실시간 통신 구현을 위해 HTTP Pooling, Long Pooling, Streaming 방법을 사용하여 Stateless 한 HTTP 통신을 Stateful 하게 사용하였고, 관련 제약이 많았음. (ex. 요청/응답 Header가 불필요하게 많이 발생)

 

Pooling, Long Pooling, Streaming

• 요청/응답에 대한 Header가 불필요하게 큼
• 양방향 실시간 통신 불가능  (단순 Request 하고 Response 하는 과정)

 

WebSocket

• Header로 Handshaking 후 순수 메시지 크기만 부담 => 네트워크 부하가 적음
• 양방향 실시간 통신 가능
• HTML5 이후만 지원하여 안정성이 조금 떨어짐

https://yubi5050.tistory.com/191

[Web 일반] 실시간 통신 (Pooling, Long Pooling, Streaming, WebSocket) 비교

 

TCP, HTTP, WebSocket 비교

👉 TCP의 3-way handshake와 4-way handshake란?

TCP/IP 프로토콜에서 연결 수립/해제 과정

• 생성 : 3-way-handshake는 [요청, 수락, 확인+데이터 전송]
• 해제 : 4-way-handshake는 [요청, 수락, 확인, 확인] - 한번 더 확인 하는 이유는 서버에서 혹시나 전송중인 메시지가 남아 있을까봐

 

3-way handshake 

• 1. SYN : 서버와 연결을 위한 요청
• 2. SYN+ACK : 요청 수락 및 Port 오픈 요청
• 3. ACK : 최종 수락 + 데이터 전송

 

4-way handshake (3번이 아닌, 4번인 이유는?)

• 1. FIN : 서버와 연결 해제를 위한 요청
• 2. FIN + ACK :서버가 CLOSE_WAIT 상태가 됨
• 3. FIN : 서버가 클라이언트에게 남은 데이터 없는지 체크 (LAST_WAIT 상태)
• 4. ACK : 최종 완료를 서버로 보냄

 

👉 HTTP 와 TCP 차이 (= HTTP는 TCP/IP 위에서 동작한다)

• HTTP에서 생성되는 데이터의 형태는 String 형태, TCP는 패킷으로 정보를 구성
• 최상위 계층인 Application 계층에서 HTTP 프로토콜에 맞춰 생성된 메시지(String 형태의 데이터)가 TCP 계층에서 메시지를 패킷으로 분해되어, 전송 위치를 확인하는 IP 계층을 통해 네트워크 전송

 

👉 WebSocket과 HTTP의 차이점은?

둘다 모두 TCP 기반으로 Application 단에서 만들어진 데이터가 TCP 계층에서 패킷으로 분해되어 전송됨 (WebSocket은 최초에 한번, HTTP는 연결시마다)

• WebSocket : 최초 커넥션된 URL만과 통신, 연결지향, 비동기식 통신, 이벤트 기반(event-driven) 아키텍처 모델
• HTTP : Stateless, 동기식-비동기식 통신 둘다 가능,  Request-Response 형태로 통신하는 단방향 통신

 

REST API, HTTP Method

👉 RESTful api란?

HTTP URI를 통해 자원을 명시하고, HTTP Method (GET, POST, DELETE, PUT) 등을 통해 해당 자원에 대한 CRUD Operation을 적용하는 것

 

👉 RESTful 하다란? 

REST의 원리를 잘 지키는 것 (URI를 작성시 underscore는 자제한다던가, 명사 위주로 URI를 구성, 데이터 조회할 때 POST 대신 GET을 사용 등)

 

👉 REST 규칙을 잘 지키지 않는 것은? 

POST로 CRUD 기능을 처리하는 것

 

👉 GET vs POST 차이는?

GET

• 자원 조회를 요청할 때 많이 사용
• 주로 Body 대신 쿼리스트링이 포함된 URL로 전송
• URL로 보낼수 있는 데이터에 한계가 있고 주로 조회 역할을 많이 수행하므로 캐싱 기능을 활용 가능

POST

• 데이터를 생성할 때 주로 사용
• Body에 데이터를 담아서 보냄
• GET과는 달리 데이터 길이에 대한 제한 x

 

👉 PUT vs POST 차이는?

POST PUT의 가장 큰 차이는 멱등성

• POST는 반복해서 요청하면 매번 결과가 다르다. (여러개가 생성되고, 멱등성이 없다)
• PUT은 반복 요청 해도 매번 결과가 같다. (추가 생성 되지 않고, 멱등성을 가진다)

 

https://yubi5050.tistory.com/164

[Web 기본] HTTP 메소드 (+ PRG 패턴)

 

👉 PRG 패턴 이란?

PRG란 (POST - Redirect - GET) POST가 요청 endpoint가 중복 실행 되어, 추가 생성 되는 것 막는 패턴 방법

POST가 가진 요청 가 재실행 되는 것, POST가 완료되면 Redirect 로 GET요청을 하게 해서, 새로고침을 하더라도 마지막 요청인 GET요청이 재실행 되게 하는 것 

https://yubi5050.tistory.com/164?category=1089352

[Web 기본] HTTP 메소드 (+ PRG 패턴)

 

👉 PATCH vs PUT 차이는?

PATCH는 수정만 담당하며 리소스의 일부분만 수정할 때 사용

PUT은 리소스의 모든 속성을 수정하기 위해 사용

 

👉 DELETE 메소드 주의점

DELETE 메소드의 API 호출시, Client의 삭제 권한에 대한 검사가 필수적

 

👉 DELETE 메소등의 SOFT DELETE vs HARD DELETE 차이

• SOFT DELETE : 데이터 복구시 이점 / 쿼리시 DELETE Flag 필드 값 참고 필요
• HARD DELETE : 데이터베이스 용량이 상대적으로 절약 / 복구 하기 힘듬 
• ex) 여부를 관리하는 컬럼 : is_deleted, removed, activate/inactivate 

 

Status Code

👉 status code 사용 이유

response 결과에 대한 클라이언트 애플리케이션이 불필요한 payload 해석 없이, 상태 결과를 공유하기 위함

• 1XX : 요청이 진행중임
• 2XX : 요청이 성공되었음 (성공적으로 조회, 생성 등)
• 3XX : 요청 완료를 위한 추가 작업 수행 (301, 302 redirect, 304-not modified 캐싱) 
• 4XX : 클라이언트의 에러를 의미 (400 Bad Request, 401 Unauthorized 인증, 403 Forbidden권한 - 사용자는 누군지 알고있음. 404 not found - 잘못된 주소 접근)
• 5XX : 서버 작업중의 에러를 의미 (500 - 서버 내 에러, ex. 503 서비스 불가로 Nginx 처리 중 실패시)

 

👉 401 (UnAuthorized) 와 403 (Forbidden)의 차이는?

• 401 unauthorized : 사용자가 인증(로그인) 되지 않은 경우
• 403 forbidden : 권한이 없는 경우 (사용자가 누군지는 알지만, 권한이 없음 ex. AWS IAM의 권한 없는 S3 Resource 접근, 토큰 전달 안해줬을 때 )

 

👉 301(Moved Permanently redirect), 302 (Found)

• 301 Moved Permanently redirect : 해당 url이 영구적으로 이동한 경우 자원도 같이 이동 (ex. 웹사이트 도메인 변경)
• 302 Found redirect : 요청한 자원의 리소스 URL이 임시적으로 새롭게 이동했을 때 

예제 문제

Q. 인기리에 팔리는 제품이 일시적으로 재고가 떨어지거나 혹은 특정한 계절이나 기간에만 한정적으로 파는 제품이였고, 보유한 사이트랭크를 유지하면서 사용자에게 일시적으로 제품이 품절됐음을 알리려면 어떻게 해야할까요?

 

301 사용 : 페이지의 컨텐트를 변경하게 되면 사이트랭킹 점수가 달라지게 됨

302 사용 : 검색엔진은 일시적으로 해당 URL의 사이트랭크는 보존 + 사용자는 새로운 URL의 컨텐트를 보게 됨

https://nsinc.tistory.com/168

[HTTP] 301과 302 Redirect의 차이

 

쿠키 & 세션 & 토큰

👉 쿠키(Cookie), 세션(Session) 등이 필요한 이유는?

HTTP는 상태에 연결에 대한 정보를 저장하지 않아 이를 도와주는 것

 

👉 쿠키(Cookie), 세션(Session), 토큰(Token) 차이

Session

• 인증을 위해 서버에서 클라이언트에 대한 정보를 가지며, 브라우저가 종료될 때 까지 유지
• 보안성이 더 좋음

 

Cookie

• 클라이언트가 가진 사용자 정보 TXT 파일로 브라우저에 저장
• 통신할 때 Header에 포함하여 전송
  ex) 클라이언트가 request시 사전에 서버로 전달받은 session id가 기록된 cookie를 header에 넣어 전송. 서버는 전송받은 session id를 바탕으로 세션 저장소 조회 및 비교
• 클라이언트 로컬에 저장 되어, 전송(Request) 간 snipping 당할 우려가 있어 보안에 취약

 

Token

• 인증에 필요한 정보를 암호화하는 방법
• 사용자는 Token을 HTTP Header에 실어 서버에 전송하고 인증 받음
• Token은 정보를 웹 브라우저에 저장하여, 보안도 낮지만 확장성이 좋음

 

👉 세션(Session) vs 토큰(Token)의 확장성의 차이

Session :  서버 확장시, 각 서버별 Session 정보가 서버별 인메모리에 따로 유지되어, 재요청시 다른 서버로 요청이 가게 되면 재인증이 필요 할 수 있음

Token : 서버 확장해도 모든 서버가 공통의 Signature를 바탕으로, Token을 해석하므로, 확장성이 더 좋음

 

https://yubi5050.tistory.com/171

[Authentication] Session/Cookie vs Token 차이

 

👉 쿠키와 세션을 쓰는 이유?

데이터 유지를 하여 불편함을 줄이기 위해, 세션은 보안이 더 높고 서버에서 정보를 관리하는 반면, 쿠키는 클라이언트에서 유지한다.  

 

👉 세션을 쓰면 되는데 쿠키를 쓰는 이유는?

세션이 쿠키에 비해 보안이 높은 편이나, 세션을 사용시 서버자원이 낭비되므로, 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 자원의 낭비를 방지하는 것이 좋음

 

👉 Session과 Cookie 차이

세션은 보안성이 좋은 대신, 세션 정보 관리로 서버에 부하를 줄 수 있고
쿠키는 서버의 부하를 주지 않지만, 로컬에 저장되어 탈취 등의 보안 문제가 있을 수 있음

 

👉 JWT에 대한 질문

https://yubi5050.tistory.com/67 // JWT Token 

 

보안 & SSL

👉 CORS 란? (+ 해결법)

Web Application에서 자신이 속하지 않은 도메인/포트의 리소스를 요청시 CORS(Cross-Origin Resource Sharing)를 Request Header 등에 포함하여 HTTP 요청을 보낸다. 

 

동일 출처가 아닌데, 데이터를 주고 받을 수 있도록 하는 것.

SOP (Same Origin Policy) 정책 때문에 CORS(교차 출처 자원 정책)로 문제를 해결

 

👉 대칭키 vs 공개키 

대칭키(Symmetric Key) : 암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘

• 동일한 키를 주고받기 때문에, 매우 빠름
• 대칭키 전달 과정에서 해킹 위험 有

 

공개키 (Public Key) / 비대칭키 (Asymmetric Key) : 암호화와 복호화에 사용하는 암호키를 분리한 알고리즘

• 자신이 가지고 있는 고유한 암호키(비밀키)로만 복호화할 수 있는 암호키(공개키)를 공개함
• 공개키와 비밀키로 분리시 공개키는 해킹 당해도 안전

 

👉 SSL 하이브리드 방식 (대칭키 + 공개키)

• 대칭키를 주고받을 때만 공개키 암호화 방식을 사용하고 이후에는 계속 대칭키 암호화 방식으로 통신

암호화 방법 (출처 : 링크)

1. A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하고 B에게 보냄
2. B는 암호문을 받고, 자신의 비밀키로 복호화함
3. B는 A로부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보냄
4. A는 자신의 대칭키로 암호문을 복호화함
5. 앞으로 이 대칭키로 암호화를 통신함

 

동기, 비동기

👉 Blocking vs Non-blocking

Blocking / Non-blocking

호출된 함수 B가 작업 시작시 제어권을 바로 돌려주느냐 차이 

• Blocking : 함수 B가 할 일을 다 마칠 때까지 A에 대한 제어권을 가지고 있는다
• Non-blocking : 함수 B가 할 일을 마치지 않았어도 A에 대한 제어권을 바로 넘겨준다.

 

👉 Sync vs Async

A가 B의 수행 결과나 종료 상태를 A가 신경쓰고 있는지에 대한 차이

• Synchronous : 함수 A는 함수 B가 작업 중 계속 신경쓰면서, 현재 상태가 어떤지 계속 체크
• Asynchronous : 함수 A는 함수 B의 수행 상태 신경쓰지 않고, B 혼자 직접 신경쓰면서 알아서 처리. 이후 Callback

즉, 호출된 함수(B)를 호출한 함수(A)가 신경쓰는지, 호출된 함수(B)가 알아서 하는지에 따라 동기/비동기

비동기는 작업 완료시 Callback을 전달하여 호출한 함수에 답함 (Callback이 오기 전까지 호출한 함수는 신경쓰지 않고 다른 작업 수행)

 

👉 Sync vs Async & Block vs Non-Block 케이스

이미지 업로드 서버 (비동기, 블록)

• 10명의 사용자가 업로드를 진행 -> 비동기로 처리시 이점 -> 10명에 대한 요청 수신을 빠르게 할 수 있음 -> 수신 중 이미지 업로드 완료시 결과 반환

 

푸쉬 알람 서버 (비동기, 논블록)

• 10명의 사용자가 푸쉬를 보냄 -> 비동기 처리 -> 요청 결과를 기다리지 않고 그냥 ok 버튼 나오고 끝 

 

기타

👉 Query-String과 Path-variable의 사용 시기는?

• Path variable : 어떤 자원(데이터)을 식별해야 할 경우 (api/media/1)
• Query parameter : 정렬 or 필터링 할 경우 (api/media?name=동영상&num=3)

 

👉 웹 브라우저 프로세스 종류

• 브라우저 프로세스 : 주소 표시줄, 북마크, 뒤/앞으로 가기 버튼, 네트워크 통신 & 파일 접근 권한
• 렌더러 프로세스 : 웹 사이트 랜더링
• 플러그인 프로세스 : 웹 사이트 플러그인 제어
• GPU 프로세스 : GPU 이용 화면 드로잉 제어