'Programming/Network'에 해당되는 글 12건

2011.08.19 FTP active모드와 passive 모드?
2009.05.12 네트워크 관련 명령어
2009.05.12 Simple Mutex Usage : shared resource (2008/05/08)
2009.05.12 [socket API] WSAEventSelect 모델
2009.05.12 [연습] WSAAsyncSelect (2007/11/01)
2009.05.12 [code] blocking server using thread (2007/11/01)
2009.05.12 [BOOK리소스] 멀티스레드 프로그래밍 소스 .zip
2009.05.12 [history] 네트워크 플그래밍 공부 발자국 순서 (2007/10/29)
2009.05.12 [src] simple tcpserver 1
2009.05.12 HTTP 프로토콜 요약: HTTP Message 구조 2
2009.05.12 HTTP 서버/클라 만들어 보기 3
2009.05.12 HOWTO: 비동기 프로시저 호출을 이용하여 Waitable 타이머 사용 하기

FTP active모드와 passive 모드?

Posted on 2011. 8. 19. 18:04
Filed Under Programming/Network

FTP 의 Active 모드와 Passive 설명▼
http://blog.naver.com/geeksblog/20028104462

Linux/Windows passive 모드 설정 방법▼
http://lovelgw.nepc.name/Blog/73

저작자표시 비영리 변경금지

네트워크 관련 명령어

Posted on 2009. 5. 12. 13:29
Filed Under Programming/Network

Ping(Packet Internet Groper)
- 대상 IP와의 연결상태 확인
- 정보: 대상의 응답 여부, 응답을 받는데 걸리는 시간(delay), 패킷 유실율
- delay : ICMP echo request packet 을 전달한 시간과 해당 Seq No.를 가진 ICMP echo reply packet을 전달받은 시간차이로 계산

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]
[-r count] [-s count] [[-j host-list] | [-k host-list]]
[-w timeout] destination-list
Options:
-t 지정된 컴퓨터에서 종료될 때까지 ping을 전달한다.
   To see statistics and continue - type Control-Break;
   To stop - type Control-C.
-a    주소를 컴퓨터 이름으로 변경한다.
-n count count에 지정된 ECHO 패킷의 수를 보낸다.
-l length length에 지정된 크기의 데이터로 ECHO 패킷을 보낸다. (기본값: 32bytes, 최대: 65,527 bytes)
-f 패킷에 Do not Fragment 플래그를 보낸다.
   이 패킷은 도중에 게이트웨이에 의해 조각으로 나누어지지 않는다.
-i TTL Time To Live 필드를 ttl에 지정된 값으로 설정한다.
-v TOS Type of Service 필드를 tos에 저징된 값으로 설정한다.
-r count 보내는 패킷과 반환된 패킷의 경로를 Record Route 필드에 기록한다. (1 <= count <= 9)
-s count count에 지정된 홉의 수에 대한 time stamp를 지정한다.
-j host-list host-list에 지정된 컴퓨터의 목록을 통해 패킷의 경로를 정한다.
   연속적인 컴퓨터는 중간 게이트웨이로 구분할 수 있다. IP가 허용하는 최대 수는 9이다.
-k host-list host-list에 지정된 컴퓨터의 목록을 통해 패킷의 경로를 정한다.
   연속적인 컴퓨터는 중간 게이트웨이로 구분할 수 없다. IP가 허용하는 최대 수는 9이다.
-w timeout 시간 초과 간격을 초단위로 지정한다.

ARP (Address Resolution Protocol)
- 로컬에서 분해된 IP주소에 대한 물리적인 주소의 캐시 내용을 보여주고 수정할 수 있다.
- Ethernet/IP주소의 변환에 관한 정보를 제공
- 용도: 로컬 네트워크 내에 IP주소가 잘못 지정되었는지를 확인

ARP -s inet_addr eth_addr [if_addr]
ARP -d inet_addr [if_addr]
ARP -a [inet_addr] [-N if_addr]

-a TCP/IP를 쿼리하여 현재ARP 항목을 표시한다.
   inet_addr를 지정하면 지정된 컴퓨터의 IP와 물리적 주소만 표시된다.
-g    Same as -a.
inet_addr 192.168.2.154 와 같은 IP주소
-N if_addr if_addr에 의해 지정된 네트워크 인터페이스의 ARP 항목올 표시한다.
ip_addr가 있으면 주소 변환 테이블을 수정해야 하는 인터페이스의 IP 주소를 지정한다.
ip_addr가 없으면 처음 적용할 수 있는 인터페이스를 사용한다.
-d inet_addr에 의해 지정된 항목을 삭제한다. 와일드카드(*) 사용가능
-s IP 주소 inet_addr가 물리적 주소 ether_addr와 연관되도록 ARP 캐시에 항목을 추가한다.
eth_addr    물리적 주소. 하이픈(-)으로 구분된 6개의 16진수 바이트로 표시된다.
if_addr If present, this specifies the Internet address of the
interface whose address translation table should be modified.
If not present, the first applicable interface will be used.
Example:
> arp -s 157.55.85.212 00-aa-00-62-c6-09 .... Adds a static entry.
> arp -a    .... Displays the arp table.

ipconfig
- TCP/IP 네트워크 구성값을 표시
- DHCP를 실행하는 시스템에서는 사용자가 DHCP에 의해 주성된 TCP/IP 구성값을 결정할 수 있게 한다.
A. 구성조회
ipconfig [/all | /renew [adapter] | /release [adapter]]
/all    전체 정보를 표시한다.
   기본 정보는 각 네트워크 카드의 IP 주소, 서브넷 마스크 및 기본 게이트웨이 값만 표시
/renew [adapter]    DHCP 구성 매개 변수를 새로 만든다.
      이 옵션은 DHCP 클라이언트 서비스를 실행하는 시스템에서만 사용가능.
   어댑터 이름을 지정하려면 매개 변수 없이 ipconfig를 사용할 때 나타나는 어댑터 이름을 입력해야한다.
/release [adapter] 현재 DHCP 구성을 해제한다.
이 옵션은 로컬 시스템에서 TCP/IP를 사용할 수 없게 하며 DHCP 클라이언트에서만 사용할 수 있다.
   어댑터 이름을 지정하려면 매개 변수 없이 ipconfig를 사용할 때 나타나는 어댑터 이름을 입력해야한다.

B. DNS 클라이언트 등록 갱신
- ipconfig /registerdns [adapter]
adapter : 등록을 갱신할 컴퓨터에 설치된 특정 네트워크 어댑터
- DNS 클라이언트 등록 갱신: 구성되어 있는 DNS 이름과 IP 주소의 동적 등록을 수동으로 시작할 수 있다.
- 디폴트로 ipconfig /registerdns 명령은 모든 DHCP 주소 임대를 새로 고치고 클라이언트 컴퓨터에서 구성하고 사용하는 관련된 모든 DNS 이름을 등록한다.
- 이 명령으로 선택적으로 지정할 수 있는 어댑터 이름을 보려면 ipconfig 명령만 입력한다.
- 실패한 DNS 이름 등록의 문제를 해결하거나 클라이언트를 다시 부팅하지 않고 클라이언트와 DNS 서버간 동적 업데이트 문제를 해결하는데 유용하다.

C. 클라이언트 확인자 캐시 표시
- ipconfig /displaydns
- 이 캐시에는 로컬 호스트 파일에서 미리 로드된 항목분 아니라 최근 시스템이 확인한 이름 쿼리에서 얻은 리소스 레코드가 포함된다.
- DNS 클라이언트 서비스는 구성되어 있는 DNS 서버에 쿼리하기 전에 이 정보를 사용하여 자주 쿼리되는 이름을 확인한다.
- ipconfig /displaydns 을 실행하면 결과에 로컬 호스트 루프백 IP 주소(127.0.0.1) 매핑이 포함된다. 이것은 로컬 호스트 파일에 수정되지 않은 기본 내용에 매핑이 있기 때문이다.

D. 클라이언트 확인자 캐시 플러시 및 재설정
- icponfig /flushdns
- DNS 클라이언트 확인자 캐시 내용을 플러시하고 재설정할 수 있다.
- 필요시 DNS 문제 해결 중에 이 단계를 사용하여 캐시에 보관된 부정 캐시 항목뿐 아니라 동적으로 추가된 다른 항목을 제거할 수 있다.

netstat
- 프로토콜 통계와 현재 TCP/IP 네트워크 연결을 표시

NETSTAT [-a] [-b] [-e] [-n] [-o] [-p protocol] [-r] [-s] [-v] [interval]

-a    모든 연결 및 수신 대기 포트를 표시합니다.
   일반적으로 서버 연결은 나타나지 않는다.
-b    각 연결 또는 수신 대기 포트를 만드는 데 관련된 실행 프로그램을
표시합니다. 잘 알려진 실행 프로그램에서 여러 독립 구성 요소를
호스팅하는 경우에는 연결 또는 수신 대기 포트를 만드는 데
관련된 구성 요소의 시퀀스가 표시됩니다. 이런 경우에는
실행 프로그램 이름이 아래쪽 대괄호 안에 표시되어 있고 위에는
TCP/IP에 도달할 때까지 호출된 구성 요소가 표시되어 있습니다.
이 옵션은 시간이 오래 걸릴 수 있으며 사용 권한이 없으면 실패합니다.
-e    이더넷 통계를 표시합니다. 이 옵션은 -s 옵션과 같이 사용될수 있습니다.
-n    이름 검색을 시도하지 않고 주소 및 포트 번호를 숫자 형식으로 표시합니다.
-o    각 연결의 소유자 프로세스 ID를 표시합니다.
-p protocol 지정한 프로토콜에 해당되는 연결을 표시한다. 프로토콜은
TCP, UDP, TCPv6 또는 UDPv6 을 사용할 수 있다.
-s 옵션과 함께 사용하여 프로토콜별 통계를 표시할 경우 프로토콜은 IP, IPv6,
ICMP, ICMPv6, TCP, TCPv6, UDP 또는 UDPv6 가 될 수 있다.
-r    라우팅 테이블을 표시합니다.
-s    프로토콜별로 통계를 표시합니다. 기본값으로 IP, IPv6, ICMP,
ICMPv6, TCP, TCPv6, UDP 및 UDPv6에 관한 통계를 표시합니다.
-p 옵션을 함께 사용하면 기본값의 일부 집합에 대한 통계만
표시할 수 있습니다.
-v    -b 옵션과 함께 사용하면 모든 실행 프로그램에 대한 연결
또는 수신 대기 포트를 만드는 데 관련된 구성 요소의 시퀀스를
표시합니다.
interval    다음 화면으로 이동하기 전에 지정한 시간 동안 선택한 통계를
다시 표시합니다. 통계 표시를 중단하려면 CTRL+C를 누르십시오.
지정하지 않으면 현재 구성 정보를 한 번 표시합니다.

route
- 한 네트워크 Hosts 또는 device까지의 경로를 추적하여 특정 주소까지의 네트워크 경로를 보여준다.
- 패킷이 루트를 찾는데 걸리는 시간을 확인하는 반응시간을 milisecond 단위로 보여주는데 이 반응시간은 네트워크 로드에 따라 다른 값을 나타나게 한다.
- ping을 실행했을 때와 같이 패킷이 전달되는 라우팅 지점들을 홉수별로 텍스트로 나타낸다.
- 네트워크 라우팅 테이블을 확인하거나 변경할 수 있다.
- 원격 호스트까지 패킷이 전행되는 동안의 라우팅 홉(hop) 정보를 보여준다.

ROUTE [-f] [-p] [command [destination]
[MASK subnetmask] [gateway] [METRIC metric] [IF interface]

-f 모든 게이트웨이 항목의 라우팅 테이블을 삭제한다.
-p add 명령과 함께 사용하면 시스템이 부팅할 때 경로를 보존하도록 만든다.
   기본적으로 시스템을 다시 시작하면 경로가 보존되지 않는다.
   print 명령과 함께 사용하면 등록된 보존 경로의 목록을 표시한다.
   (Windows 95 에서는 지원안됨)
command 다음중 하나 지정
   PRINT : 경로 인쇄
   ADD    : 경로 추가
   DELETE : 경로 삭제
   CHANGE : 기존 경로 수정
destination 명령을 보낼 호스트를 지정한다.
MASK subnetmask 경로 항목과 연결된 서브넷 마스크를 지정한다.
지정하지 않으면 255.255.255.255가 사용된다.
gateway 게이트웨이를 지정한다.
distination이나 gateway에 사용되는 모든 기호 이름은 Networks라는 네트워크 데이터베이스 파일과 Hosts라는 컴퓨터 데이터베이스 파일에서 모두 참조된다.
interface 특정 라우터의 인터페이스 번호
METRIC 가장 빠르고 신뢰할 수 있으며 비용이 가장 적게 드는 경로를 계산하는데 사용되는 정수 코스트 메트릭(1~9999)을 지정한다.

Examples:
> route PRINT
> route ADD 157.0.0.0 MASK 255.0.0.0 157.55.80.1 METRIC 3 IF 2
   destination^    ^mask    ^gateway metric^    ^
   Interface^
If IF is not given, it tries to find the best interface for a given
gateway.
> route PRINT
> route PRINT 157*    .... Only prints those matching 157*
> route CHANGE 157.0.0.0 MASK 255.0.0.0 157.55.80.5 METRIC 2 IF 2

CHANGE is used to modify gateway and/or metric only.
> route PRINT
> route DELETE 157.0.0.0
> route PRINT

tracert
- 연결문제 발생시 연결하고자 하느 대상 IP 주소를 확인하고 결과를 기록할 수 있다.
- 컴퓨터에서 대상으로 패킷을 전달하는데 사용되는 일련의 IP 라우터와 각 홉에 걸리는 시간이 표시
- 대상까지 미도달시 패킷을 성공적으로 전달한 마지막 라우터가 표시
- 대상에 대한 다양한 TTL(Time-To-Live) 값으로 ICMP(Internet Control Message Protocol) 에코 패킷을 보내 대상으로 가는 경로를 결정한다. 경로 상의 각 라우터에서 패킷을 전달하기 전에 최소한 패킷의 TTL을 1만큼 줄여야 홉 수 계산에 TTL이 효과를 낼 수 있다. 패킷의 TTL이 0에 도달하면 라우터에서 ICMP 시간 초과 메시지를 원본 시스템으로 돌려보낸다고 가정한다.
- tracert 는 대상이 응답하거나 최대 TTL에 도달할 때까지의 1의 TTL을 가진 첫째 에코 패킷을 보내고 이어지는 각 전송에서 TTL을 1씩 증가시켜 경로를 결정한다. 경로는 중간 라우터들에서 반송한 ICMP 시간 초과 메시지를 검사하여 결정된다. 일부 라우터는 TTL 값이 만료된 패킷을 제거하기 때문에 tracert에서 볼 수 없는 경우도 있다.

Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

Options:
-d 주소를 컴퓨터 이름으로 풀지 않도록 지정한다.
-h maximum_hops 대상을 검색할 최대 홉 수를 지정한다.
-j host-list host-list에 따라 신축적 원본 경로를 지정한다.
-w timeout timeout에 지정된 milisecond 동안 응답을 기다린다.
target_name 대상 컴퓨터 이름

<출처: 실무자를 위한 네트워크 관리의 이해, 이종일, Jinhan M&B>

pathping=ping+tracert(traceroute)

♣ 참고사이트

저작자표시 비영리 변경금지

Simple Mutex Usage : shared resource (2008/05/08)

Posted on 2009. 5. 12. 13:28
Filed Under Programming/Network

HANDLE hMutex = CreateMutex(NULL, FALSE, NULL);
ASSERT(hMutex);
WaitForSingleObject(hMutex, INFINITE);

// 리소스 사용

ReleaseMutex(hMutex);

저작자표시 비영리 변경금지

[socket API] WSAEventSelect 모델

Posted on 2009. 5. 12. 13:28
Filed Under Programming/Network

- event object를 생성하고 이를 이용해 소켓 이벤트를 등록하여 통보받아 처리하는 방식
- WSAAsyncSelect와 달리 윈도우가 아니어도 된다.

이벤트 생성
WSAEVNT WSACreateEvenv(void);

이벤트 등록
int WSAEventSelect(
SOCKET s, // 이벤트를 받으려는 소켓
WSAEVENT hEventObject, // 이벤트를 전달받으려는 이벤트 오브젝트
long lNetworkEvents // 이벤트 종류들(bitmask)
);

이벤트 오브젝트를 시그널 상태로,
BOOL WSAResetEvent(WSAEVENT hEvent);

이벤트 오브젝트 사용이 끝나면,
BOOL WSACloseEvent(WSAEVENT hEvent);

저작자표시 비영리 변경금지

[연습] WSAAsyncSelect (2007/11/01)

Posted on 2009. 5. 12. 13:27

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

비밀번호 ::

[code] blocking server using thread (2007/11/01)

Posted on 2009. 5. 12. 13:22

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

비밀번호 ::

[BOOK리소스] 멀티스레드 프로그래밍 소스 .zip

Posted on 2009. 5. 12. 13:20

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

비밀번호 ::

[history] 네트워크 플그래밍 공부 발자국 순서 (2007/10/29)

Posted on 2009. 5. 12. 13:09
Filed Under Programming/Network

1. tcpechoserver/tcpechoclient : 블로킹 모드 / 단일 클라이언트 접속

2. html protocol 적용하여 만든 서버에 익스플로러(클라이언트)를 이용해 접속해보고 테스트
   [ GET / HTTP/1.1 → HTTP/1.1 200 OK ]

3. 쓰레드 사용: 다중 접속 지원을 위해 ListenThread와 RecvThread 쓰레드 함수를 만들어 돌려보자!
서버는 받은 메시지를 접속된 모든 클라이언트에 echo해준다.
[ WaitForMultipleObjects, CreateThread/CloseHandle ]
   → 문제점: 서버에서 받는 메시지가 여러 클라이언트에서온 메시지와 엉켜버렸다.

4. select 를 사용해보자! (쓰레드는 사용 안함) : blocking or nonblocking
[ struct fd_set, select, FD_ZERO, FD_SET, FD_CLR, FD_ISSET ]

typedef struct fd_set {
   u_int fd_count;
   SOCKET fd_array[FD_SETSIZE];
   } fd_set;

5. nonblocking i/o model: WSAAsyncSelect : 윈도우 기반

6.

저작자표시 비영리 변경금지

[src] simple tcpserver

Posted on 2009. 5. 12. 13:08

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

비밀번호 ::

HTTP 프로토콜 요약: HTTP Message 구조

Posted on 2009. 5. 12. 13:07
Filed Under Programming/Network

[1] Request: Client → Server

Request    = Request-Line    ; Section 5.1
*(( general-header    ; Section 4.5
   | request-header ; Section 5.3
   | entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ]    ; Section 4.3

예:)
GET /webmatter/235026_1.jpg HTTP/1.1CRLF
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*CRLF
Accept-Language: koCRLF
Accept-Encoding: gzip, deflateCRLF
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)CRLF
Host: localhostCRLF
Connection: Keep-AliveCRLFCRLF

[2] Response: Server → Client

Response = Status-Line ; Section 6.1
   *(( general-header    ; Section 4.5
| response-header    ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
   CRLF
   [ message-body ]    ; Section 7.2

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Status-Code 종류별
#	종류	상세히
1xx	Informational	참고 정보로 클라이언트의 요청이 접수되었고 현재 처리하고 있다는 의미입니다. 클라이언트에서 첨부문서(attatched document)를 보내기 전에 요청을 보낼때 Expect헤더에 설정해서 보냅니다. 잠적적인 응답을 표시하며 Status-Line과 선택적인 헤더로 구성되어 있습니다. 이 클래스는 빈 라인으로 종료되고 HTTP/1.0은 어떠한 1xx 상태 코드로 정의하지 않기 때문에 실험적인 상황 이외에 서버는 1xx 응답을 HTTP/1.0 클라이언트에 발송해서는 안됩니다.
2xx	Success	요청 받은 것이 성공적으로 처리되었음을 나타냅니다. 이 상태 코드 클래스는 클라이언트의 요구가 성공적으로 수신, 해석 및 접수되었음을 표시합니다.
3xx	Redirection	파일들이 이동되었을 때 쓰이며, 이동하는 위치를 나타내는 Location 헤더가 응답에 포함됩니다. 이 상태 코드 클래스는 사용자 에이전트가 요구를 완전히 처리하기 위해서는 추가적인 처리가 필요하다는 것을 표시합니다. 요구되는 처리는 두 번째 요구에 사용된 method가 GET 또는 HEAD일 경우에만 사용자와의 상호작용 없이도 수행될 수 있습니다. 사용자 에이전트는 이러한 방향 재설정이 무한 루프를 표시하는 것이기 때문에 다섯 번 이상 자동적으로 요구 방향 재설정을 해서는 안 됩니다.
4xx	Client Error	클라이언트의 요청이 불안전하며, 클라이언트 요청을 성공시키려면 다른 정보가 필요하다는 것을 말합니다. 상태 코드의 4xx 클래스는 클라이언트가 에러를 발생한 것처럼 보일 경우에 사용됩니다. HEAD 요구에 응답하는 경우를 제외하고는 서버는 임시적이건 영구적이건 에러 상황에 대한 설명을 포함한 엔터티를 포함해야 합니다. 이러한 상태 코드는 모든 요구 method에 적용할 수 있습니다. 사용자 에이전트는 사용자에게 포함된 엔터티를 표시해야 합니다. [주] 클라이언트가 데이터를 발송한다면 TCP를 사용하는 서버 구현 방식은 서버가 입력 접속을 종료하기 전에 응답을 포함하고 있는 패킷 접수를 확인할 수 있도록 주의해야 합니다. 클라이언트가 접속이 종료된 후에도 계속해서 데이터를 전송한다면 서버의 TCP 스택은 리셋 패킷을 클라이언트에게 발송할 것입니다. 이 리셋 패킷은 HTTP 애플리케이션이 읽거나 해석하기 전에 클라이언트가 확인한 입력 버퍼를 지웁니다.
5xx	Server Error	서버가 에러를 발생시켰으며 요구를 처리할 능력이 없음을 인지한 경우를 표시합니다. HEAD 요구에 응답하는 때를 제외하고는 서버는 에러 상황에 대한 설명및 에러가 잠정적인지 영구적인지에 관한 상황 설명을 포함하는 엔터티를 포함해야 합니다. 사용자 에이전트는 포함된 모든 엔터티를 사용자에게 표시하여야 한다. 이러한 응답 코드는 모든 요구 method에 적용할 수 있습니다.

Status-Code | Reason-Phrase

100 Continue (계속)
요청된 초기 부분은 접수되었고 클라이언트는 계속해서 요청할 수 있다는 것입니다.
이 잠정적인 응답은 클라이언트에게 응답의 시초 부분이 수신되었으며 서버가 아직 거부하지 않았음을 알리는 데 사용합니다. 클라이언트는 요구의 나머지 부분을 발송하여야 하며 요구가 완료 되었으면 이 응답을 무시해야 합니다. 서버는 요구가 완료된 다음 마지막 응답을 발송합니다.

101 Switching Protocols (프로토콜 변환)
서버는 Upgrade 헤더 필드에 명시된 프로토콜로 교환하기 위한 클라이언트 요청에 따르고 있다는 것을 말합니다.
서버가 이해하였으며 기꺼이 Upgrade 메시지 헤더 필드를 통하여 접속에 사용되고 있는 애플리케이션 규약 변경에 관한 클라이언트의 요구에 따릅니다. 서버는 101 응답을 종료하는 빈 라인 바로 다음 응답 메시지의 Upgrade 헤더 필드가 정의한 규약으로 전환할 것입니다.

규약은 전환하는 것이 유리한 경우에만 전환됩니다. 예를 들어 새로운 버전의 HTTP로 전환하는 것이 이전 버전을 사용하는 것보다 유리하며 해당 기능을 사용하는 자원을 배달할 때 실시간, 동시 규약으로 전환하는 것이 유리합니다.

200 OK
클라이언트의 요청이 성공적이었으며, 서버는 요청한 데이터를 포함하여 응답합니다.
응답과 함께 리턴 되는 정보는 요구에 사용된 method에 달려 있습니다.

예를 들면:
GET 요구한 자원에 상응하는 엔터티는 응답에 포함되어 발송됩니다.
HEAD 요구한 자원에 상응하는 Entity-Header 필드는 Message-Body 없이 응답에 포함되어 발송됩니다.
POST 처리 결과를 설명 또는 포함하는 엔터티.
TRACE 수신 서버가 수신한 요구 메시지를 포함하고 있는 엔터티.

201 Created (생성 되었음)
새로운 URI가 만들어질 때마다 사용되며 결과 코드와 함께 새로운 데이터가 위치한 곳을 지정하기 위해 Location 헤더가 서버에 의해 주어집니다.
원서버는 201 상태 코드를 리턴하기 전에 반드시 자원을 생성해야 합니다. 처리가 즉각적으로 수행될 수 없을 때에 서버는 202(Accepted) 응답으로 대신 응해야 합니다.

202 Accepted (접수 되었음)
클라이언트이 요청을 받아들이기만 했을 뿐 아직 완료되지 않은 상태를 나타냅니다.
처리를 위해 응답을 접수하였으나 처리는 완료되지 않았다는 의미로 요구는 엔터티의 처리 과정에서 허용되지 않을 수도 있기 때문에 궁극적으로 처리될 수도 있고 처리되지 않을 수도 있습니다. 이와 같은 동시 작업에서 상태 코드를 재발송하는 설비는 없습니다.

202 응답은 의도적으로 작업을 수행하지 않습니다. 이 응답의 목적은 서버가 사용자 에이전트가 프로세스가 완료될 때까지 서버에 지속적으로 연결되지 않고도 다른 프로세스에 대한 요구(하루에 한 번만 실행되는 배치 지향적인 프로세스일 수도 있습니.)를 접수할 수 있도록 하는 데 있습니다. 이 응답을 리턴하는 엔터티는 상태 점검자(monitor)에 대한 지시자 또는 사용자가 언제 요구가 완료될 수 있는지에 대한 예상 및 요구의 현재 상태에 대한 표시를 포함해야 합니다.

203 Non-Authoritative Information(비 인증 정보)
Entity-Header의 리턴 된 메타 정보는 서버에서 사용할 수 있는 정의 세트가 아니고 지역 또는 제 3 자의 복사본에서 수집한 것입니다.
제시된 세트는 원래 버전의 하부 세트 또는 상위 세트일 수 있습니다. 예를 들어 자원에 대한 지역적 주해 정보를 포함하면 원서버가 알고 있는 메타 정보에 대한 상위 세트를 만들어 낼 수도 있습니다. 이 응답 코드를 사용하는 것은 의무사항이 아니며 응답이203이 아니면 200 (OK)일때만 적합합니다.

204 No Content(내용이 없음)
응답할때 주어지는 헤더이나 응답된 실제 내용이 없다는 뜻입니다.
새로운 문서가 없어서 브라우저에게 이전 문서를 계속 표시하라고 알려주는 것으로 서버가 요구를 완전히 처리 했으나 반송할 새로운 정보가 없다는 것으로 클라이언트가 사용자 에이전트이면 요구를 발송하도록 한 문서 내용을 변경해서는 안 됩니다.

이런 응답을 받는 이유는 웹브라우저가 문서를 보기위해 갱신을 하지 않았기 때문입니다. 이미지맵에서 클라이언트가 이미지의 영역중 사용하지 않거나 공백인 부분을 클릭했을 때를 처리할 때 유용합니다.

205 Reset Content(내용을 지움)
새로운 문서가 없더라도 브라우저에서 창을 초기화하고, 문서를 새로 표시한다는 것입니다.
서버가 요구를 완전히 처리하였으며 사용자 에이전트는 요구를 발송하도록 한 문서의 내용을 지워야합니다. 이 응답은 주로 사용자 입력을 통하여 처리를 위한 입력이 발생하도록 하기 위해 사용합니다. 이 응답 뒤에 입력을 수행한 폼을 지워 사용자가 다른 입력 요구를 쉽게 시작할 수 있게 합니다. 이 응답은 엔터티를 포함해서는 안 됩니다.

웹브라우저가 추가적인 입력을 위해 사용된 트랜잭션을 지우는 것으로 CGI 애플리케이션에서 데이터를 입력받을때 적합합니다.

206 Partial Content(부분적 내용)
서버가 요청된 크기의 데이터를 반환하고 있다는 것입니다.
Range 헤더 지정 요청에 응답하는데 이용됩니다. 이 요구는 반드시 원하는 영역을 표시하는 Range 헤더 필드를 포함해야 합니다. 응답은 이 응답에 포함된 영역을 표시하는 Content-Range 헤더 필드나 각 파트의 Content-Range 필드를 포함하는 multipart/byteranges Content-Type을 포함해야 합니다. multipart/byteranges를 사용하지 않았으면 응답의Content-Length 헤더 필드는 Message-Body로 전송된 OCTET의 실제 숫자와 정확하게 일치해야 합니다.

Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206(Partial Content) 응답을 캐시해서는 안됩니다.

300 Multiple Choices (복수 선택)
요청된 문서가 여러곳에 있을때 어떤 문서를 원하는지를 묻는 것입니다.
요구된 자원이 각자 자신 특유의 위치를 가지고 있는 표현 세트 중의 하나와 대응되며 사용자(또는 사용자 에이전트)가 선호하는 표현 방식을 선택하고 요구를 해당 위치로 재설정할 수 있도록 에이전트가 주도하는(agent-driven) 협상 정보가 제공됩니다.

HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함합니다. 엔터티 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시됩니다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있습니다. 그러나 이 규격은 이러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않습니다.

서버가 선호하는 표시 방법을 가지고 있으면 Location 필드에 해당 표시 방법에 대한 상세한 URL을 포함해야 합니다. 사용자 에이전트는 Location 필드 값을 이용하여 자동으로 방향을 재설정할 수 있습니다. 이 응답은 별도의 표시가 없는 한 캐시할 수 있습니다.

301 Moved Permanently (영구 이동)
요청된 문서의 위치가 영구적으로 변했음을 나타내는 것입니다.
요구된 자원에 새로운 영구 URI가 할당되었으며 향후 이 자원에 대한 참조는 리턴 된 URI 중 하나를 이용하여 이루어질 수 있습니다. 링크를 편집할 수 있는 능력이 있는 클라이언트는 가능하다면 Request-URI 에 대한 참조를 서버가 리턴한 하나 또는 그 이상의 새로운 참고처로 자동적으로 재링크시켜야 합니다. 다르게 표시되어 있지 않으면 이 응답은 캐시할 수 있습니다.

이 새로운 URL은 응답 메시지의 Location 필드로부터 전달된 것이어야 하는데, HEAD 요구의 경우가 아니라면 응답의 Entity-Body는 새로운 URL에 대한 하이퍼링크를 가진 짤막한 설명문을 갖고 있어야 합니다.

만약 POST 요구에 대한 응답으로 301 상태코드가 수신되면 사용자 에이전트는 사용자로부터 확인을 받지 않은 상태에서 요구 메시지를 자동 방향전환 시켜서는 안 됩니다. 왜냐하면 이것이 요구 메시지를 발생시킨 상황 조건에 대한 변화를 줄 수 있기 때문입니다.

[주] 301 상태코드를 수신한 후에 POST 요구를 자동 방향전환시키면 현재의 어떤 사용자 에이전트는 GET 요구로 바꾸어버리는 오류상황을 만들기도 합니다.

302 Found
요청된 URI는 일시적으로 새로운 URI를 가집니다.
Location 헤더는 새로운 장소를 가리킨다. 만일 이것이 GET 이나 HEAD 메소드에 대한 응답이라면 클라이이언트는 응답을 받자마자 요청을 해결하기 위해 새로운 URI를 사용해야 합니다.

303 See Other(다른 것을 참조)
요구된 자원이 별도의 URI(Location 헤더에 명시한)에 임시로 보관되어 있으며 해당 자원에서 GET method를 사용하여 조회해야 합니다.
이 method는 주로 POST가 활성화한 스크립트의 산출물을 사용자 에이전트가 선택된 자원으로 방향을 재설정할 수 있도록 하기 위해 사용됩니다. 새로운 URI는 처음 요구된 자원에 대한 대체 참고처가 아닙니다. 303 응답은 캐시할 수 없으나 두 번째(재설정된) 요구에 대한 응답은 캐시할 수 있습니다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는 사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구의 방향을 재설정해서는 안 됩니다.

304 Not Modified(변경되지 않았음)
브라우저의 캐시에 들어있는 문서가 최신 문서이니 그것을 그대로 사용하라는것을 나타냅니다.
클라이언트가 조건적 GET 요구를 실행했고 접근할 수 있으나 문서가 변경되지 않았으면 서버는 이 상태코드로 응답해야 합니다. 이 응답은 Message-Body를 포함해서는 안 됩니다.

응답은 다음의 헤더 필드를 포함하고 있어야 합니다.

조건적 GET이 강한 캐시 검증자를 사용했다면 응답은 다른 Entity-Header를 포함해서는 안 됩니다. 그렇지 않으면(조건적 GET이 약한 캐시 검증자를 사용할 때) 응답은 Entity-Header을 포함해서는 안 됩니다. 이렇게 하여 캐시 된 Entity-Body과 갱신된 헤더 사이의 불일치를 방지할 수 있습니다.
304 응답이 현재 캐시 되지 않은 엔터티를 표시할 때 캐시는 이 응답을 무시하고 조건 없이 요구를 반복해야 합니다.
캐시가 수신한 304 응답을 캐시 엔트리의 갱신에 사용한다면 캐시는 응답이 가지고 있는 새로운 필드 값을 반영하기 위해 엔트리를 반드시 갱신해야 한다.
304 응답은 Message-Body를 포함해서는 안되므로 항상 헤더 필드 다음의 첫 공백 라인으로 종료되어야 합니다.

305 Use Proxy(프락시를 사용할 것)
요청된 문서를 프록시를 통해서만 전송 받으라는 것을 나타냅니다.
요구된 자원을 Location 필드에 명시된 프락시를 통하여 접근해야만 합니다. Location 필드가 프락시의URL을 제공합니다. 수신측은 프락시를 통한 요구를 반복할 것으로 기대됩니다.

307 Temporary Redirect(임시 이동)
요청된 URI가 일시적으로 옮겨졌다는 뜻입니다.
Location 헤더가 새로운 장소를 가르킵니다. 이 상태 코드를 받는 즉시, 클라이언트는 요청을 해결하기 위해 새로운 URI를 사용해야 하지만 앞으로 모든 요청들은 이전의 URI를 사용할 것입니다.

400 Bad Request(잘못된 요구)
클라이언트의 요청에 문법적인 오류가 있다는 것을 서버가 알아냈다는 것을 의미합니다.
잘못된 형식 때문에 서버가 요구를 이해할 수 없습니다. 클라이언트는 변경 없이 요구를 반복해서는 안 됩니다.

401 Unauthorized (인증되지 않았음)
클라이언트가 잘못된 인증정보를 Authorization 헤더에 넣었음을 나타냅니다.
응답이 사용자 인증을 요구합니다. 이 응답은 요구된 자원에 적용할 수 있는 설명 요구(challenge)를 포함하고 있는 WWW-Authenticate 헤더 필드를 포함하고 있어야 합니다. 클라이언트는 적절한 Authorization 헤더 필드를 가지고 요구를 반복할 수 있습니다. 요구가 벌써 Authorization 증명서를 포함하고 있다면 401 응답은 해당 증명서에 대한 인증이 거절되었음을 표시합니다. 401 응답이 이전 응답과 동일한 설명 요구를 포함하고 있고 사용자 에이전트가 한 번 이상 인증 획득을 시도했다면 해당 엔터티가 관련된 진단 정보를 포함하고 있기 때문에 사용자에게 응답에 표시된 엔터티를 표시해주야 합니다.

402 Payment Required
이 코드는 아직 HTTP로 구현되지 않았습니다. 하지만 언젠가는 서버의 문서를 받아보기 위해 지불이 필요하다는 것을 나타냅니다.

403 Forbidden(금지되었음)
클라이언트의 인증정보에 상관없이 페이지에 대한 접근을 거부한다는 것을 나타냅니다.
서버가 요구를 이해했으나 완료하는 것을 거절하고 있다는 의미로 인증은 적용되지 않으며 요구를 반복될 수 없습니다. 요구 method가 HEAD가 아니고 서버가 왜 요구가 완료되었는지 알리고 싶다면 엔터티 안에 거절한 이유를 기록해야 합니다. 이 상태 코드는 서버가 요구가 거부 사유를 밝히기 원하지 않을 때나 다른 응답을 적용할 수 없을 때 일반적으로 사용됩니다.

404 Not Found(찾을 수 없음)
클라이언트가 요청한 자원에 서버에 없다는 것을 나타냅니다.
서버가 Request-URI와 일치하는 것을 아무것도 발견하지 못했다는 의미로 이러한 상태가 잠정적인지 영구적인지 관한 아무런 표시도 주어지지 않은 경우입니다.

서버가 이 정보를 클라이언트에게 알리고 싶지 않을 경우 상태 코드 403(Forbidden)을 대신 사용할 수 있습니다. 내부적으로 환경을 설정할 수 있는 메커니즘을 통하여 이전의 자원을 영구적으로 사용할 수 없으며 전송 주소가 없다는 것을 알 수 있으면 410(Gone) 상태 코드를 사용합니다.

405 Method Not Allowed(Method를 사용할 수 없음)
Allow 헤더와 함께 클라이언트가 사용한 메소드가 이 URI에 대해 지원되지 않는다는 의미입니다.
Request-Line에 명시된 method를 Request-URI로 확인할 수 있는 자원에서 사용할 수 없습니다.
응답은 요구된 자원에 사용할 수 있는 method의 목록을 포함한 Allow 헤더를 포함해야 합니다.

406 Not Acceptable(접수할 수 없음)
클라이언트가 지정한 URI는 존재하지만 클라이언트가 원하는 형식이 아닙니다.
코드와 함께 서버는 Content-Language, Content-Encoding, Content-Type 헤더를 제공합니다. HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함합니다. 엔터티 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시됩니다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있습니다. 그러나 이 규격은 그러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않습니다.

[주] HTTP/1.1 서버는 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는 응답을 리턴할 수 있게 합니다. 어떤 경우엔 이것이 406 응답을 발송하는 것보다 좋을 수도 있습니다. 사용자 에이전트는 도착하는 응답의 헤더를 검사하여 그것의 접수 여부를 결정하도록 추천합니다. 응답을 접수할 수 없을 때 사용자 에이전트는 잠정적으로 더 이상의 데이터를 수신하지 말아야 하며 추가 행동을 취할 것인지 사용자에게 질의합니다.

407 Proxy Authentication Required(프락시 인증 필요)
이 코드는 401(Unauthorized)과 유사하지만 클라이언트는 먼저 프락시에서 자기 자신을 인증해야 한다는 것을 표시 하는 것으로 proxy 서버로 로그온 한 후에 다시 시도해 봐야 합니다.
프락시는 요구된 자원의 프락시에 적용할 수 있는 설명 요구를 포함하는 Proxy-Authenticate 헤더 필드를 리턴해야 합니다. 클라이언트는 적절한 Proxy-Authorization 헤더 필드와 함께 요구를 반복해야 합니다.

408 Request Timeout(요구 시간 초과)
클라이언트의 모든 요청이 지정한 시간(일반적으로 서버를 구성할때 명시한다) 동안 처리되지 않았음을 의미합니다.
서버는 네트워크를 끊습니다. 클라이언트가 서버가 기다리도록 준비한 시간 내에 요구를 만들어 낼 수 없는 경우며 클라이언트는 나중에 변경 없이 요구를 반복할 수 있습니다.

409 Conflict(충돌)
다른 요청이나 서버의 구성과 충돌이 있음을 나타냅니다.
충돌에 대한 정보는 응답되는 데이터의 일부로 반환됩니다. 이 코드는 사용자가 충돌을 해결하고 요구를 재전송할 수 있을 것으로 기대할 수 있는 상황에서만 사용할 수 있습니다. 응답 본문은 사용자가 충돌의 원인을 인지할 수 있도록 충분한 정보를 포함해야 합니다. 이상적으로는 응답 엔터티가 사용자 또는 사용자 에이전트가 문제를 해결할 수 있을 정도의 충분한 정보를 포함할 수 있을 것입니다. 그러나 가능하지 않을 수도 있으며 필수 사항은 아닙니다.

충돌은 PUT 요구에 대한 응답으로 발생할 가능성이 높습니다. 버전 관리를 사용하고 있고 PUT 요구를 하는 엔터티가 이전 요구(제 3 자)가 작성한 요구와 충돌되는 자원에 대한 변경 사항을 포함하고 있다면 서버는 409 응답을 사용하여 요구를 완료할 수 없음을 표시해야 합니다. 이 경우 응답 엔터티는 응답 Content-Type이 규정한 형식으로 두 버전 사이의 차이점 목록을 포함해야 합니다.

410 Gone (내용물이 사라졌음)
요청된 문서가 사라지고, 새로운 주소는 알 수 없다는 것을 나타냅니다.
요구된 자원이 서버에 더 이상 존재하지 않으며 전송 주소를 알 수 없는 경우입니다. 이 조건은 영구적인 것으로 간주해야 합니다. 링크를 편집할 기능이 있는 클라이언트는 사용자 인증 후의 Request-URI에 대한 참고는 삭제해야 합니다. 서버가 그 조건이 영구적인지 여부를 알 수 없거나 결정할 시설이 없으면 상태 코드 401(Unauthorized)을 대신 사용해야 합니다. 다르게 표시되지 않는 한 이 응답은 캐시할 수 있습니다.

410 응답은 주로 수신측에게 자원을 의도적으로 사용할 수 없게 하였고 서버의 소유주가 해당 자원에 대한 원격 링크를 제거하고자 한다는 것을 알림으로써 웹 유지 작업을 지원하기 위해 사용됩니다. 이러한 일은 제한된 시간, 선전용 서비스 및 서버의 사이트에서 더 이상 일하지 않는 개인에게 소속된 자원에서 공통적으로 발생할 수 있습니다. 영구적으로 사용할 수 없는 모든 자원을 "사라진" 것으로 표시하거나 특정 시간 동안 표시를 유지할 필요는 없습니다.

411 Length Required(길이가 필요함)
서버가 규정된 Content-Length 없는 요구 접수를 거부하였다는 의미로 요구 메시지 내의 Message-Body의 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가한다면 클라이언트는 요구를 반복할 수 있습니다.

412 Precondition Failed(사전 조건 충족 실패)
하나 또는 그 이상의 Request-Header에 명시된 조건에 의해 요청을 평가하여 false값을 가지는 경우입니다. 이 응답 코드는 클라이언트가 현재 자원의 메타 정보에 사전 조건을 부여할 수 있게 하여 의도하지 않는 자원에 요구 method를 적용하는 것을 방지합니다.

413 Request Entity Too Large(요구 엔터티가 너무 큼)
서버는 실제 본문이 너무 커서 요청을 처리할 수 없다는 것을 의미합니다.
요구 엔터티가 서버가 처리할 수 있거나 처리하려는 것보다 크기 때문에 서버가 요구 처리를 거부하는 경우로 서버는 클라이언트가 계속적으로 요구하는 것을 방지하기 위하여 연결을 종료합니다.

조건이 잠정적이면 서버는 Retry-After 헤더 필드를 포함하여 조건이 잠정적이며 얼마 후에 클라이언트가 재시도할 것인지를 표시합니다.

414 Request-URI Too Long(Request -URI가 너무 김)
서버는 요청된 URI가 너무 커서 요청을 처리할 수 없다는 것을 의미합니다.
Request-URI가 서버가 해석할 수 있는 것보다 크기 때문에 서버가 요구 처리를 거부하는 경우로 이처럼 드문 조건은 클라이언트가 부적절하게 질의 정보가 긴 POST 요구를 GET 요구로 변환했을때, 클라이언트가 방향 재설정의 URL "블랙 홀"로 빠졌을 때(방향이 재설정된 URL 접두사가 자신의 접미사를 지칭할 때), Request-URI를 읽거나 조작하는 고정-길이 버퍼를 사용하는 몇몇 서버에 존재하는 보안의 허점을 이용하려는 클라이언트로부터 서버가 공격을 받을 때만 발생하는 것 같습니다.

415 Unsupported Media Type(지원되지 않는 media type)
서버는 실제 본문이 지원되지 않는 형식이라 처리할 수 없다는 의미입니다.
요구의 엔터티가 요구 받은 method의 자원이 지원하지 않는 포맷으로 구성되어 있기 때문에 요구처리를 거부하였다는 의미입니다.

416 Requested range not satisfiable
서버는 어떤 유효한 값도 포함하지 않은 Range 헤더를 찾아냈습니다.
추가로 If-Range헤더는 없어졌습니다.

417 Expectation Failed
Exept헤더에서 명시된 조건은 만족될 수 없습니다.

500 Internal Server Error(서버 내부 에러)
서버의 일부(예를 들어 CGI 프로그램)가 멈추었거나 설정에서 오류(잘못된 결과나 적절하지 않은 헤더를 생성시키는 경우)가 나타났음을 의미합니다.

501 Not Implemented(구현되지 않았음)
클라이언트의 요청된 행위가 서버에서 수행할 수 없음을 의미합니다.
이것은 서버가 요구 method를 인지할 수 없고 어떠한 자원을 사용해도 지원할 수 없을 때 적절한 응답입니다.

502 Bad Gateway(불량 게이트웨이)
서버(또는 프락시)가 다른 서버(또는 프록시)로 부터의 응답이 적절하지 않음을 의미합니다.
게이트웨이나 프락시 역할을 수행하는 서버가 요구를 완료하려는 시도에서 접근한 업스트림(upstream) 서버로부터 유효하지 않은 응답을 수신했을 경우입니다.

503 Service Unavailable(서비스를 사용할 수 없음)
서비스를 일시적으로 제공할 수 없으나, 앞으로 복구된다는 의미입니다.
서버가 현재 잠정적인 오버로딩(overloading)이나 서버의 유지 작업 때문에 요구를 처리할 수 없다는 것으로 이것이 잠정적인 상황이며 얼마 후에는 완화될 수 있다는 것입니다. 알 수 있다면 지연 시간 길이를 Retry-After 헤더에 표시할 수 있습니다. 아무런 Retry-After 정보가 없으면 클라이언트는 500 응답을 처리하는 것처럼 응답을 처리해야 합니다.

[주] 503 상태 코드가 있다는 것이 서버가 오버로드 되었을 때 이것을 반드시 사용해야 된다는것을 의미하지 않습니다. 어떤 서버는 단순히 접속을 거부하고자 합니다.

504 Gateway Timeout(게이트웨이 시간 초과)
게이트웨이나 프락시 역할을 수행하는 서버가 시간 내에 요구를 완료하려는 시도에서 접근한 업스트림(upstream) 서버로부터 응답을 수신하지 못했을 경우입니다.

게이트웨이나 프락시의 시간이 경과했다는 것만 빼고는 408(Request time-out)과 같습니다.

505 HTTP Version Not Supported(지원되지 않는 HTTP 버전)
서버가 요구 메시지에서 사용된 HTTP 규약 버전을 지원하지 않거나 지원하기를 거부했다는 의미입니다.
서버는이 에러 메시지 이외에는 클라이언트가 사용하는 동일한 주요 버전을 사용하여 요구를 완료할 의사나 능력이 없음을 표시합니다. 응답은 왜 해당 버전이 지원되지 않으며 서버가 어떤 규약을 지원하는가를 설명하는 엔터티를 포함해야 합니다.

예:)
HTTP/1.1 200 OK <-Status-Line
Date: Wed, 08 Oct 1997 11:40:24 GMT <-general-header
Server: Apache/1.3a1 <-response-header
Last-Modified: Wed, 08 Oct 1997 11:40:06 GMT <-entity-header
ETag: "0-1e4-343b7116" <-entity-header
Content-Length: 484 <-entity-header
Accept-Ranges: bytes <-entity-header
Content-Type: text/html <-entity-header

출처: Hypertext Transfer Protocol -- HTTP/1.1 [RFC 2616]
Status Code 출처: HTTP Status Code(HTTP 1.1 : RFC 2616)

저작자표시 비영리 변경금지

HTTP 서버/클라 만들어 보기

Posted on 2009. 5. 12. 13:05

보호되어 있는 글입니다. 내용을 보시려면 비밀번호를 입력하세요.

비밀번호 ::

HOWTO: 비동기 프로시저 호출을 이용하여 Waitable 타이머 사용 하기

Posted on 2009. 5. 12. 13:04
Filed Under Programming/Network

타이머(알람) 만들때 좋은 녀석이란다.
기회되면 한번 써보잣!! When..?

[CODE] // SetWaitableTimer.cpp : 콘솔 응용 프로그램에 대한 진입점을 정의합니다.
//
#define _WIN32_WINNT 0x0400
#include "stdafx.h"

#include <windows.h>
#include <stdio.h>

#define _SECOND 10000000

typedef struct _MYDATA {
TCHAR *szText;
DWORD dwValue;
} MYDATA;

VOID CALLBACK TimerAPCProc(
LPVOID lpArg,    // Data value.
   DWORD dwTimerLowValue,    // Timer low value.
   DWORD dwTimerHighValue ) { // Timer high value.

MYDATA *pMyData = (MYDATA *)lpArg;

printf( "Message: %s\nValue: %d\n\n", pMyData->szText,
pMyData->dwValue );
//MessageBeep(0);

}

void main( void )
{

HANDLE    hTimer;
BOOL    bSuccess;
__int64 qwDueTime;
LARGE_INTEGER liDueTime;
MYDATA    MyData;
TCHAR szError[255];

MyData.szText = "This is my data.";
MyData.dwValue = 100;

if ( hTimer = CreateWaitableTimer(
   NULL,    // Default security attributes.
   FALSE,    // Create auto-reset timer.
   "MyTimer" ) )    // Name of waitable timer.
{

__try {

// Create a negative 64-bit integer that will be used to
// signal the timer 5 seconds from now.
qwDueTime = -5 * _SECOND;

// Copy the relative time into a LARGE_INTEGER.
liDueTime.LowPart = (DWORD) ( qwDueTime & 0xFFFFFFFF );
liDueTime.HighPart = (LONG) ( qwDueTime >> 32 );

bSuccess = SetWaitableTimer(
hTimer, // Handle to the timer object.
&liDueTime, // When timer will become signaled.
2000, // Periodic timer interval of 2 seconds.
TimerAPCProc, // Completion routine.
&MyData, // Argument to the completion routine.
FALSE ); // Do not restore a suspended system.

if ( bSuccess ) {

for ( ; MyData.dwValue < 1000; MyData.dwValue += 100 ) {

SleepEx(
INFINITE, // Wait forever.
TRUE ); // IMPORTANT!!! The thread must be in an
// alertable state to process the APC.
}

} else {
wsprintf( szError, "SetWaitableTimer() failed with Error %d.",
GetLastError() );
MessageBox( NULL, szError, "Error", MB_ICONEXCLAMATION );
}

} __finally {
CloseHandle( hTimer );
}

} else {
wsprintf( szError, "CreateWaitableTimer() failed with Error %d.",
GetLastError() );
MessageBox( NULL, szError, "Error", MB_ICONEXCLAMATION );
}

}[/CODE]

출처: http://support.microsoft.com/kb/601487/ko