CS 공부 - 2

1. HTTP 응답코드에 대해 설명해 주세요.

HTTP 응답 코드는 웹 서버가 클라이언트에게 보내는 상태를 설명하는 코드입니다. 이 코드는 서버의 처리 결과를 나타내며, 클라이언트가 요청한 작업이 성공적으로 완료되었는지, 실패했는지, 그리고 어떤 종류의 오류가 발생했는지를 나타냅니다. HTTP 응답 코드는 세 자리 숫자로 이루어져 있으며, 각 코드에는 특정한 의미가 부여되어 있습니다.

가장 일반적인 HTTP 응답 코드에는 다음과 같은 것들이 있습니다:

• 1xx (Informational): 요청을 받았으며 처리 중임을 나타냅니다.
• 2xx (Success): 요청이 성공적으로 수행되었음을 나타냅니다.
• 3xx (Redirection): 요청을 완료하기 위해 추가 조치가 필요함을 나타냅니다.
• 4xx (Client Error): 클라이언트의 요청에 오류가 있음을 나타냅니다.
• 5xx (Server Error): 서버에서 요청을 처리하는 동안 오류가 발생했음을 나타냅니다.

1. 401 (Unauthorized) 와 403 (Forbidden)은 의미적으로 어떤 차이가 있나요?

401 에러 : 클라이언트가 인증되지 않았거나 유효한 인증 정보가 부족하여 요청이 거부되었음을 의미하는 상태값이다.

ex) 로그인이 안된 상태에서 로그인을 해야만 접근 가능한 영역에 접근 시도할 때 발생

 

403 에러 : 서버가 요청을 이해했지만 권한이 없어 요청이 거부되었음을 의미한다.

ex) 로그인이 된 상태에서 다른 사람의 게시글 등을 수정 / 삭제 시도할 때 발생

 

참고 링크

[HTTP] HTTP 상태 401(Unauthorized) vs 403(Forbidden) 차이 - MangKyu's Diary (tistory.com)

[HTTP] HTTP 상태 401(Unauthorized) vs 403(Forbidden) 차이

 

2. 200 (ok) 와 201 (created) 의 차이에 대해 설명해 주세요.

200 (ok) : 클라이언트의 요청을 서버가 정상적으로 처리했음을 의미한다.

 

201 (created) : 클라이언트의 요청을 서버가 정상적으로 처리했고 새로운 리소스가 생겼음을 의미한다.

 

참고 링크

🌐 2XX (Successful) 상태 코드 - 총정리 모음 (tistory.com)

🌐 2XX (Successful) 상태 코드 - 총정리 모음

 

3. 필요하다면 저희가 직접 응답코드를 정의해서 사용할 수 있을까요? 예를 들어 285번 처럼요.

나무위키에 비표준 응답코드에 대한 언급이 있는 것으로 보아 가능할 것으로 추측됨

https://namu.wiki/w/HTTP/%EC%9D%91%EB%8B%B5%20%EC%BD%94%EB%93%9C#s-7

HTTP/응답 코드

 

2. HTTP Method 에 대해 설명해 주세요.

1. GET: 서버로부터 특정 리소스(일반적으로 웹 페이지)를 가져옵니다. GET 요청은 주로 데이터를 서버에 보내지 않고 정보를 요청할 때 사용됩니다.
2. POST: 서버에 새로운 데이터를 전송합니다. 주로 양식 데이터를 서버로 제출할 때 사용됩니다. POST 요청은 데이터를 요청 본문에 담아 전송합니다.
3. PUT: 서버에 새로운 데이터를 전송하거나 리소스를 업데이트합니다. 요청 본문에 전송된 데이터로 지정된 위치에 새로운 리소스를 만들거나 업데이트합니다.
4. DELETE: 서버에서 특정 리소스를 삭제합니다. 요청 본문에 삭제할 리소스의 정보가 포함되어 있어야 합니다.
5. PATCH: 리소스의 부분적 업데이트를 수행합니다. PUT과 달리 PATCH는 리소스의 일부분만 업데이트합니다.
6. HEAD: GET과 유사하지만, 서버는 실제 데이터를 반환하지 않고 헤더만 반환합니다. 주로 리소스의 메타데이터를 가져올 때 사용됩니다.
7. OPTIONS: 서버가 지원하는 HTTP 메서드를 요청합니다. 서버는 이에 대한 응답으로 허용되는 메서드 목록을 반환합니다.
8. TRACE: 클라이언트 요청이 서버에 도달할 때까지의 경로를 따라 클라이언트로 되돌려줍니다. 일반적으로 디버깅 용도로 사용됩니다.
9. CONNECT: 목적지 서버로의 터널을 설정합니다. 주로 프락시 서버와의 통신에 사용됩니다.

 

HTTP Method의 멱등성에 대해 설명해 주세요.

멱등성의 정의 : 동일한 요청을 한 번 보내는 것과 여러 번 연속으로 보내는 것이 같은 효과를 지니고 서버의 상태도 동일하게 남는 것을 의미한다.

 

멱등성을 가진 메서드

 

GET : 처음 요청과 동일한 상태를 유지

PUT : 데이터를 덮어쓰기 하는 것으로 만약 요청 시 수정할 데이터를 일부분만 보내면 보낸 데이터 외의 데이터는 NULL로 표현된다.

DELETE : DELETE도 삭제를 함으로써 처음과 다른 응답 값을 주지만 서버상태가 바뀌지 않는다.

 

멱등성을 가지지 않은 메서드

 

POST : POST는 요청을 보낼 때마다 새로운 데이터를 생성함을 예상함으로써 처음 서버의 상태와 여러번 요청했을 때의 서버 상태가 다르다. 그러므로 멱등성을 가지지 않는다.

 

참고 링크

[HTTP] HTTP 멱등성이란?? — 개발관 (tistory.com)

[HTTP] HTTP 멱등성이란??

 

GET과 POST의 차이는 무엇인가요?

• GET : 클라이언트에서 서버로 어떤 리소스에게 정보를 요청하기 위해 사용되는 메서드
• POST : 클라이언트에서 서버로 리소스를 생성하거나 업데이트하기 위해 데이터를 보낼 때 사용되는 메서드

참고 링크

[네트워크] get 과 post 의 차이 :: 인생의 로그캣 (tistory.com)

[네트워크] get 과 post 의 차이

 

POST와 PUT, PATCH의 차이는 무엇인가요?

POST vs PUT

 

POST

• 보통 INSERT의 개념으로 사용
• 삽입, 수정, 삭제 다 POST로 가능하지만, 적절하게 함수를 나눠 사용하는 것이 좋다.
• 클라이언트가 리소스의 위치를 지정하지 않음 (/profile)
• 따라서, 요청을 여러 번 수행하면 매번 새로운 profile이 생성된다.
  (profile/3, profile/4 등 매번 새로운 자원이 생성)
• 안전함 X, 멱등성 X

PUT

• 보통 UPDATE의 개념으로 사용
• 클라이언트가 리소스의 위치를 명확하게 지정함 (/profile/3 또는 /profile/4)
• 따라서, 아무리 많이 수행 하더라도 동일한 리소스를 수정하기 때문에 여러 번 요청 하더라도 멱등하다.
• 안전함 X, 멱등성 O
• 리소스를 변경하는 과정에서 서버의 변화가 있으나, 매번 같은 응답을 받는다.

 

PUT vs PATCH

 

PUT

• 해당 자원의 전체 교체를 의미
• 따라서 동일한 리소스에 대해 여러 번 PUT을 수행하면 동일한 결과를 응답한다.
• 안전함 X, 멱등성 O

PATCH

• 해당 자원의 일부 변경을 의미
• 따라서 동일한 리소스에 대해 여러 번 PATCH를 수행하면 그 일부분을 여러 번 변경한 다른 결과를 응답한다.
• 안전함 X, 멱등성 X
• 리소스를 변경하는 과정에서 서버의 변화가 있고, 매번 다른 응답을 받는다.

 참고 링크

GET, POST, PUT, PATCH 비교 | Joie-Kim

GET, POST, PUT, PATCH 비교

 

HTTP 1.1 이후로, GET에도 Body에 데이터를 실을 수 있게 되었습니다. 그럼에도 불구하고 왜 아직도 이런 방식을 지양하는 것일까요?

Body를 실어 GET 요청을 보낸다면 길이에 제약이 생기고 가독성도 떨어진다. 또한 URL 인코드가 되면 특수기호와 같은 문자들을 사용할 수 없는 상황도 생긴다.

 

참고 링크

https://velog.io/@minidoo/WEB-Restful-API-%EC%84%A4%EA%B3%84-%ED%8C%81

[WEB] (Restful) API 설계 팁

 

3. HTTP에 대해 설명해 주세요.

HTTP는 웹 브라우저와 웹 서버 간에 데이터를 전송하기 위한 프로토콜로, 클라이언트의 요청에 따라 서버가 콘텐츠를 제공하고 응답하는 데 사용됩니다.  

 

공개키와 대칭키에 대해 설명해 주세요.

대칭키

• 장점 : 암호화방식에 속도가 빠르다. 대용량 Data 암호화에 적합하다.
• 단점 : 키를 교환해야 하는 문제, 탈취 관리 걱정, 사람이 증가할수록 키관리가 어려워짐, 확장성 떨어짐
• Session Key, Secret Key, Shared Key, 대칭키, 단용키라고도 함
• 기밀성을 제공하나, 무결성/인증/부인방지 를 보장하지 않음
• 대표적 알고리즘 : 공인인증서의 암호화방식으로 유명한 SEED, DES, 3DES, AES, ARIA, 최근 주목받고 있는 암호인 ChaCha20

공개키

• 단점 : 속도가 느림
• 장점 : 키분배 필요 X, 기밀성/인증/부인방지 기능 제공
• 방식
  • 암호 모드 : 송신자 공개키로 암호화 -> 송신자 사설키로 복호화
    소량의 메시지 암호화 목적, 주로 키 교환의 용도로 사용
  • 인증 모드 : 송신자 사설키로 암호화 -> 송신자 공개키로 복호화
    메시지를 인증(부인방지)하는 것이 목적
• 대표적인 알고리즘
  • Diffie Hellman : 최초의 공개키 알고리즘, 위조에 취약
  • RSA : 대표적 공개키 알고리즘
  • DSA : 전자서명 알고리즘 표준
  • ECC : 짧은 키로 높은 암호 강도, 빠른 구현 가능 PDA, 스마트폰등에 사용

참고 링크

대칭키 vs 공개키(비대칭키) (velog.io)

대칭키 vs 공개키(비대칭키)

 

왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

 

만일 HTTPS에서 대칭키를 사용할 경우 최초 한 번은 서버에서 클라이언트로 암호화에 사용할 키를 전달해야 하는데, 그 과정에서 암호화 키를 누군가 탈취한다면 누군가 암호화/복호화 가능한 키를 가지고 있기 때문에 암호화 통신을 하더라도 무용지물이 된다. (누군가 데이터를 복호화해서 정보를 다 해석할 수 있다.)

비대칭키를 사용할 경우 서버는 개인키/공개키를 둘 다 가지고 있고, 클라이언트에서 요청할 때 공개키만 준다. 이 공개키로 암호화한 데이터는 서버만 가지고 있는 '개인키'로만 복호화 가능하다. 그리하여 누군가 공개키를 탈취하고 데이터를 탈취하더라도 데이터를 복호화할 수 없게 된다. 하지만 처리 속도가 느려 성능에 문제가 생길 수 있다.

HTTPS는 각각의 단점을 보완하기 위해 대칭키/비대칭키 방식을 혼합하여 사용한다. 최초 한 번 서버가 공개키/개인키를 가지고 있다가 클라이언트가 요청 시 공개키를 전달해준다. 클라이언트는 실제 데이터 전달에 사용할 대칭키를 공개키로 암호화하여 서버에 전달한다. 서버는 개인키를 사용해 대칭키를 복호화하고 그 후 대칭키로 실제 통신이 이루어진다. (이러한 방식을 사용하면 최초 핸드셰이킹 시에만 비대칭키 알고리즘을 사용하니 속도 저하의 문제도 해결되고, 대칭키 전달 시 대칭키를 비대칭키로 암호화하니 중간에 대칭키가 탈취되어도 누군가가 복호화할 수 없는(사용할 수 없는) 키가 되기에 보안적으로도 안전하다.) 이러한 대칭키는 HTTPS 통신 과정에서 세션키로 불린다.

 

참고 링크

HTTPS 도대체 왜 쓰는 거야? | HTTPS, SSL Handshake — 준성 스페이스 (tistory.com)

HTTPS 도대체 왜 쓰는 거야? | HTTPS, SSL Handshake

 

SSL과 TLS의 차이는 무엇인가요?

SSL과 TLS의 정의

• SSL : SSL은 컴퓨터 네트워크를 통해 통신 보안을 제공하는 C언어로 작성된 암호화 프로토콜. 데이터의 무결성과 기밀성 보장.
• TLS : TLS는 인터넷을 통한 보안 통신을 위한 표준. 클라이언트 / 서버 애플리케이션이 도청 및 정보 변조를 방지하도록 설계됨.

SSL vs TLS

• 메시지 인증 : SSL은 메시지 인증 코드(MAC)를 사용하여 전송 중에 메시지가 변조되지 않도록 한다. TLS는 보호를 위해 MAC을 사용하지 않고 대신 암호호와 같은 다른 수단을 사용하여 변조를 방지한다.
• 기록 프로토콜 : TLS에서는 패킷당 하나의 레코드만 가져올 수 있지만 SSL에서는 패킷당 여러 개의 레코드가 전송될 수 있다.
• 사이퍼 스위트 : TLS는 암호화 및 암호 해독에 사용되는 알고리즘인 다양한 암호 제품군을 지원한다.
• 알림 메시지 : SSL 프로토콜은 경고 메시지를 사용하여 통신 중 특정 오류에 대해 클라이언트 또는 서버에 알린다. TLS 프로토콜에는 이와 동등한 메커니즘이 없다.

간단히 말해, SSL은 더 이상 사용되지 않으며, TLS는 현재 모든 사람이 사용하는 암호화 표준으로 구식 SSL 프로토콜을 대체하는 새로운 용어이다.

 

참고 링크
SSL과 TLS: 차이점, 비교 등! (powerdmarc.com)

SSL과 TLS: 차이점, 비교 등!