Q, get/post/put/delete 요청 시 타임아웃이 발생하면 대처법은 무엇인가요?
재시도 로직 구현:
타임아웃이 발생하면 자동으로 요청을 재시도하도록 코드를 작성합니다. 이때, 재시도 횟수와 간격을 설정하여 서버 과부하를 방지합니다.
예: 재시도 3회, 각 재시도 간격 2초
백오프(Backoff) 전략:
재시도할 때마다 대기 시간을 기하급수적으로 늘리는 방식입니다. 이를 통해 서버 과부하를 완화할 수 있습니다.
예: 첫 재시도는 1초, 두 번째 재시도는 2초, 세 번째 재시도는 4초
로깅과 모니터링:
타임아웃 발생 시 로그를 남기고 모니터링 시스템을 통해 문제를 추적합니다. 이를 통해 원인을 파악하고 대응할 수 있습니다.
타임아웃 설정 조정:
요청의 타임아웃 시간을 늘리거나 줄여서 적절한 타임아웃 값을 설정합니다. 예를 들어, 긴 시간이 필요한 작업에는 타임아웃을 늘리고, 짧은 시간이 필요한 작업에는 타임아웃을 줄입니다.
캐싱 사용:
서버의 부하를 줄이기 위해 응답 데이터를 캐싱하여 동일한 요청에 대해 빠르게 응답할 수 있도록 합니다.
적절한 오류 메시지 반환:
클라이언트에게 타임아웃이 발생했음을 알리는 적절한 오류 메시지를 반환하여 사용자 경험을 개선합니다.
네트워크 문제 확인:
클라이언트와 서버 간의 네트워크 상태를 점검하여 문제를 해결합니다. 네트워크 연결 상태나 방화벽 설정을 확인합니다.
풀백(Fallback) 전략:
타임아웃이 발생했을 때 대체 경로나 방법을 사용하는 전략입니다. 예를 들어, 주 서버가 응답하지 않을 경우 백업 서버로 요청을 보내거나, 기본값을 반환하거나, 캐시된 데이터를 사용하는 방법이 있습니다.
try {
response = sendRequestToPrimaryServer();
} catch (TimeoutException e) {
response = sendRequestToBackupServer();
}
타임아웃이란?
타임아웃은 네트워크 요청이 일정 시간 내에 완료되지 않을 경우, 요청을 중단하고 실패로 간주하는 것을 말합니다. 이는 클라이언트가 서버로부터 응답을 기다리는 시간의 한계치를 설정함으로써, 무한 대기 상태를 방지하고 자원을 효율적으로 관리하기 위해 사용됩니다. 타임아웃은 서버 부하, 네트워크 문제, 잘못된 설정 등 다양한 원인으로 발생할 수 있습니다.
타임아웃관련 http 상태코드
408 Request Timeout: 클라이언트가 서버로부터 일정 시간 내에 응답을 받지 못함.
502 Bad Gateway: 프록시 서버가 업스트림 서버로부터 잘못된 응답을 받음.
503 Service Unavailable: 서버가 과부하 상태이거나 유지보수 중임.
504 Gateway Timeout: 프록시 서버가 업스트림 서버로부터 일정 시간 내에 응답을 받지 못함.
522 Connection Timed Out (Cloudflare): 클라우드플레어가 웹 서버로부터 응답을 받지 못함.
524 A Timeout Occurred (Cloudflare): 클라우드플레어가 웹 서버로부터 일정 시간 내에 응답을 받지 못함.
Q. HTTP METHOD 중 대표적으로 많이 쓰이는 것들을 설명해주세요.
HTTP 메소드는 서버의 리소스와 상호작용하는 동사입니다.
GET: 데이터 조회, 캐시 활용 가능. / 서버에서 리소스를 가져옵니다
POST: 데이터 생성 및 제출, 서버 상태 변경./ 서버에서 데이터를 처리하기 위해 데이터를 전송합니다
PUT: 데이터 전체 업데이트, 클라이언트가 전송한 리소스로 대체. / 서버의 리소스를 업데이트 합니다
DELETE: 데이터 삭제, 자원의 제거. / 서버의 리소스를 삭제합니다
PATCH: 데이터 일부 업데이트, 리소스의 부분적 수정. / 서버의 리소스를 일부 업데이트합니다
Q. HTTP 상태코드에 대해 설명해주세요.
HTTP 상태코드는 서버가 클라이언트의 요청을 어떻게 처리했는지 나타내는 3자리 숫자입니다.
1xx는 정보 / 요청이 접수되었지만 아직 처리되지 않았음을 알려줍니다
2xx는 성공 / 요청이 정상적으로 처리되었음을 알려줍니다
3xx는 리다이렉션/ 더 많은 정보를 요청하기 위해 다른URL을 참조할 것을 요청합니다
4xx는 클라이언트 오류 / 요청이 잘못되었거나 유효하지 않은 리소스에 접근하려고 했음을 알려줍니다
5xx는 서버 오류 / 서버에서 처리중에 문제가 발생함을 알려줍니다
| 상태코드 |
설명 |
범주 |
| 1xx (정보) |
|
|
| 100 |
Continue: 클라이언트가 요청의 나머지 부분을 계속 보내도 좋음 |
정보 |
| 101 |
Switching Protocols: 프로토콜 변경 수락 |
정보 |
| 102 |
Processing: 서버가 요청을 받았으나 처리 중임, 웹 DAV 확장 |
정보 |
| 2xx (성공) |
|
|
| 200 |
OK: 요청이 성공적으로 처리됨 |
성공 |
| 201 |
Created: 요청이 성공적으로 처리되었으며, 새로운 리소스가 생성됨 |
성공 |
| 202 |
Accepted: 요청이 수락되었으나 처리 완료되지 않음 |
성공 |
| 203 |
Non-Authoritative Information: 요청이 성공했으나 응답이 원본 데이터가 아님 |
성공 |
| 204 |
No Content: 요청이 성공적으로 처리되었으나 반환할 콘텐츠 없음 |
성공 |
| 205 |
Reset Content: 요청이 성공적으로 처리되었으며, 클라이언트는 문서 보기 영역을 리셋해야 함 |
성공 |
| 206 |
Partial Content: 요청된 리소스의 일부만 반환됨 |
성공 |
| 207 |
Multi-Status: 여러 상태 코드 응답, 웹 DAV 확장 |
성공 |
| 3xx (리다이렉션) |
|
|
| 300 |
Multiple Choices: 요청한 리소스에 대한 여러 선택지가 있음 |
리다이렉션 |
| 301 |
Moved Permanently: 요청한 리소스가 영구적으로 새로운 위치로 이동됨 |
리다이렉션 |
| 302 |
Found: 요청한 리소스가 일시적으로 다른 위치로 이동됨 |
리다이렉션 |
| 303 |
See Other: 요청 후 다른 URL로 리다이렉션 |
리다이렉션 |
| 304 |
Not Modified: 클라이언트가 캐시된 리소스를 사용해도 좋음 |
리다이렉션 |
| 305 |
Use Proxy: 요청한 리소스를 접근하기 위해 프록시를 사용해야 함 |
리다이렉션 |
| 306 |
Switch Proxy: 과거의 상태 코드, 현재는 사용되지 않음 |
리다이렉션 |
| 307 |
Temporary Redirect: 요청한 리소스가 일시적으로 다른 URL로 이동됨 |
리다이렉션 |
| 308 |
Permanent Redirect: 요청한 리소스가 영구적으로 다른 URL로 이동됨 |
리다이렉션 |
| 4xx (클라이언트 오류) |
|
|
| 400 |
Bad Request: 요청이 잘못되어 서버가 처리할 수 없음 |
클라이언트 오류 |
| 401 |
Unauthorized: 인증이 필요함 |
클라이언트 오류 |
| 402 |
Payment Required: 결제 필요, 현재는 사용되지 않음 |
클라이언트 오류 |
| 403 |
Forbidden: 요청한 리소스에 대한 접근이 금지됨 |
클라이언트 오류 |
| 404 |
Not Found: 요청한 리소스를 서버에서 찾을 수 없음 |
클라이언트 오류 |
| 405 |
Method Not Allowed: 요청한 메서드가 리소스에 대해 허용되지 않음 |
클라이언트 오류 |
| 406 |
Not Acceptable: 요청한 리소스의 형식을 클라이언트가 수용하지 않음 |
클라이언트 오류 |
| 407 |
Proxy Authentication Required: 프록시 서버 인증이 필요함 |
클라이언트 오류 |
| 408 |
Request Timeout: 요청 처리 중 타임아웃 발생 |
클라이언트 오류 |
| 409 |
Conflict: 요청이 현재 서버 상태와 충돌함 |
클라이언트 오류 |
| 410 |
Gone: 요청한 리소스가 서버에서 영구적으로 삭제됨 |
클라이언트 오류 |
| 411 |
Length Required: 요청에 Content-Length 헤더가 필요함 |
클라이언트 오류 |
| 412 |
Precondition Failed: 요청 전제 조건이 실패함 |
클라이언트 오류 |
| 413 |
Payload Too Large: 요청 본문이 너무 큼 |
클라이언트 오류 |
| 414 |
URI Too Long: 요청 URI가 너무 길어 처리할 수 없음 |
클라이언트 오류 |
| 415 |
Unsupported Media Type: 요청된 미디어 타입이 지원되지 않음 |
클라이언트 오류 |
| 416 |
Range Not Satisfiable: 요청된 범위가 리소스에 적합하지 않음 |
클라이언트 오류 |
| 417 |
Expectation Failed: Expect 요청 헤더의 기대가 실패함 |
클라이언트 오류 |
| 418 |
I'm a teapot: 과거의 상태 코드, 현재는 사용되지 않음 |
클라이언트 오류 |
| 421 |
Misdirected Request: 요청이 잘못된 서버로 전송됨 |
클라이언트 오류 |
| 422 |
Unprocessable Entity: 요청은 잘 형성되었으나 처리할 수 없음 |
클라이언트 오류 |
| 423 |
Locked: 요청한 리소스가 잠겨 있어 접근할 수 없음 |
클라이언트 오류 |
| 424 |
Failed Dependency: 이전 요청의 실패로 현재 요청이 실패함 |
클라이언트 오류 |
| 426 |
Upgrade Required: 요청한 프로토콜 업그레이드 필요 |
클라이언트 오류 |
| 428 |
Precondition Required: 요청에 전제 조건이 필요함 |
클라이언트 오류 |
| 429 |
Too Many Requests: 클라이언트가 너무 많은 요청을 보냄 |
클라이언트 오류 |
| 431 |
Request Header Fields Too Large: 요청 헤더 필드가 너무 큼 |
클라이언트 오류 |
| 451 |
Unavailable For Legal Reasons: 법적 사유로 리소스 사용 불가 |
클라이언트 오류 |
| 5xx (서버 오류) |
|
|
| 500 |
Internal Server Error: 서버 내부에서 예기치 않은 오류 발생 |
서버 오류 |
| 501 |
Not Implemented: 서버가 요청한 메서드를 지원하지 않음 |
서버 오류 |
| 502 |
Bad Gateway: 게이트웨이 또는 프록시 서버가 업스트림 서버로부터 잘못된 응답을 받음 |
서버 오류 |
| 503 |
Service Unavailable: 서버가 일시적으로 사용할 수 없거나 과부하 상태 |
서버 오류 |
| 504 |
Gateway Timeout: 게이트웨이 또는 프록시 서버가 업스트림 서버로부터 응답을 받지 못함 |
서버 오류 |
| 505 |
HTTP Version Not Supported: 서버가 요청된 HTTP 프로토콜 버전을 지원하지 않음 |
서버 오류 |
| 506 |
Variant Also Negotiates: 서버가 콘텐츠 협상에 오류가 발생함 |
서버 오류 |
| 507 |
Insufficient Storage: 서버의 저장소가 부족하여 요청을 처리할 수 없음 |
서버 오류 |
| 508 |
Loop Detected: 서버가 무한 루프를 감지함 |
서버 오류 |
| 510 |
Not Extended: 요청된 리소스를 처리하기 위해 추가 확장이 필요함 |
서버 오류 |
| 444 |
No Response: 서버가 클라이언트에 응답하지 않음, Nginx 특정 |
서버 오류 |
Q. Connection timeout/ Read timeout 차이에 대해 설명하세요.
Connection Timeout:
서버와의 연결을 설정하는 과정에서 발생하는 타임아웃입니다.
클라이언트가 서버에 연결을 시도하고, 지정된 시간 내에 연결이 성공적으로 수립되지 않으면 Connection timeout이 발생합니다.
// 연결시간초과
Read Timeout:
서버와의 연결이 성공적으로 설정된 후, 서버로부터 데이터를 읽는 과정에서 발생하는 타임아웃입니다.
서버가 클라이언트의 요청을 처리하고 데이터를 전송하는 동안 지정된 시간 내에 응답이 없으면 Read timeout이 발생합니다.
//읽기시간초과
Q. 사용자가 도메인을 치려고 하는데 접속이 안된다. 무엇을 확인해야 할까요?
DNS 설정: 도메인의 DNS 레코드가 올바르게 설정되었는지 확인합니다.
네트워크 연결: 인터넷 연결 상태 및 라우터 설정을 점검합니다.
웹 서버: 웹 서버가 정상적으로 작동하는지 확인합니다.
방화벽 설정: 방화벽이 요청을 차단하는지 확인합니다.
브라우저 캐시: 캐시 문제로 접속이 안될 수 있으므로 캐시를 삭제한 후 재시도합니다.
포트 문제: 웹 서버가 사용하는 포트(HTTP는 80, HTTPS는 443)가 열려 있는지 확인합니다.
IP 주소 문제: 도메인이 올바른 IP 주소로 매핑되어 있는지 확인합니다. IP 주소가 잘못되었거나 변경된 경우 DNS 레코드를 업데이트해야 합니다.
도메인 주소 만료: 도메인 이름이 만료되었는지 확인합니다. 도메인이 만료되면 연장해야 합니다.
Q. 대칭키/비대칭키 암호화 차이에 대해서 설명해주세요.
대칭키암호화 :
대칭키암호화는 암호화와 복호화에 동일한 키를 사용하는 방식입니다.
장점:
1.속도가 빠릅니다
2. 비교적 계산비용이 적습니다
단점:
1. 동일한 키를 사용하므로 관리가 어려울 수 있습니다
2. 키가 노출되면 전체 데이터가 위험할 수 있습니다
비대칭키암호화(공개키):
비대칭키암호화는 두 개의 서로다른키를 사용하여 하나는 암호화에 사용되는 공개키,
다른 하나는 복호화에 사용되는 개인키입니다.
공개키로 암호화된 데이터는 개인키로만 복호화가 가능합니다.
장점:
1.공개키를 배포할 수 있습니다. // 개인키만 관리하면 됨
2. 공개키로 암호화된 데이터는 해당 공개키와 연결된 개인키로만 복호화할 수 있어 보안성이 높습니다
단점:
1. 암복호화 속도가 상대적으로 느립니다
2. 계산비용이 상대적으로 더 들어갑니다
Q. 패스워드는 어떤 식으로 암호화 하는게 좋을까요?
권장방법은 단방향 해시 암호화입니다.
단반향 해시 암호화는 암호화된 데이터를 복호화할 수 없어 보안성이 높습니다
단방향 해시 암호화는 해시된 데이터로부터 원래의 데이터를 복원할 수 없습니다. 이는 해시 값이 원래 데이터의 고유한 지문 역할을 하며, 보안성을 높입니다. 이로 인해 해커가 해시 값을 알아도 원래의 패스워드를 알 수 없으므로 패스워드 저장에 적합합니다.
단방향암호화:
단방향 암호화는 데이터를 암호화한 후, 암호화된 값을 원래 데이터로 복호화할 수 없는 방식입니다. 주로 해시 함수가 사용됩니다.
과정:
1.입력: 원래 데이터를 해시 함수에 입력합니다.
2.해싱: 해시 함수는 입력 데이터를 고정 길이의 해시 값으로 변환합니다.
3.저장: 생성된 해시 값은 데이터베이스에 저장됩니다.
4.검증: 입력된 데이터가 유효한지 확인할 때는 같은 해시 함수를 사용하여 해시 값을 비교합니다.
양방향암호화:
양방향 암호화는 데이터를 암호화한 후, 동일한 방식으로 복호화하여 원래 데이터로 되돌릴 수 있는 방식입니다. 주로 대칭키 암호화 및 비대칭키 암호화가 사용됩니다.
과정:
1.입력: 원래 데이터를 암호화 알고리즘에 입력합니다.
2.암호화: 암호화 알고리즘과 키를 사용하여 데이터를 암호화합니다.
3.저장: 암호화된 데이터는 저장됩니다.
4.복호화: 데이터를 원래 형태로 복원하기 위해 같은 암호화 알고리즘과 키를 사용하여 복호화합니다.
Q. 웹소켓의 동작방식을 설명해주세요.
웹소켓이란?
웹 브라우저와 서버 간의 상호작용을 실시간으로 처리할 수 있는 통신 프로토콜입니다. 전통적인 HTTP 요청/응답 모델과는 달리, 웹소켓은 지속적인 양방향 통신을 가능하게 합니다. 웹소켓을 사용하면 클라이언트와 서버 간에 지속적인 연결을 유지하면서 데이터 전송을 효율적으로 처리할 수 있습니다.
동작방식
핸드쉐이크: 클라이언트가 웹소켓 서버에 HTTP 요청을 보내며 웹소켓 연결을 요청합니다. //웹소켓은 HTTP 통신으로 핸드쉐이킹한다.
연결 설정: 핸드쉐이크가 완료되면, 클라이언트와 서버 간에 웹소켓 연결이 설정됩니다.
양방향 통신: 연결이 설정된 후, 클라이언트와 서버는 지속적으로 데이터 프레임을 주고받으며 실시간으로 상호작용합니다.
연결 종료: 클라이언트 또는 서버가 연결을 종료하고자 할 때, 연결 종료 요청을 보내고 상대방이 이를 수락함으로써 연결이 종료됩니다.
Q. 로그를 따로 관리할 아키텍처 구성하는 방법을 설명해주세요.
로그 관리 아키텍쳐는 다음과 같이 구성할 수 있습니다
데이터수집: 애플리케이션, 서버 , 네트워크 장비등의 다양한 소스에서 로그를 log agent 또는 shipper를 사용하여 수집합니다
데이터저장: 수집된 로그를 데이터베이스, 파일시스템 또는 클라우드 기반의 로그관리 솔루션에 저장합니다.
데이터처리: 데이터 처리 도구와 기술을 사용하여 로그를 필터링, 정규화, 발전합니다
데이터분석: 분석도구 , 대시보드 , 보고서를 사용하여 처리된 로그를 분석하여 트렌드, 패턴, 이상을 식별합니다
데이터보존: 규제 요구사항 또는 회사 정책에 따라 로그를 지정된 기간 동안 보존합니다.
데이터보관: 오래된 로그를 오프사이트 또는 클라우드 저장소에 보관합니다.
//수집,저장,처리,분석,보전/보관