Suriin ang huling tugon ng FTP bago pagkatiwalaan ang isang pag-upload

Maaaring tanggapin ng kliyenteng FTP ang utos na put matagal bago matanggap ng server ang file, at sa pagitan ng dalawang pangyayaring ito naninirahan ang karamihan ng hiwaga ng pag-upload. Apat na yugto ang dapat makumpleto: binabasa ang lokal na file, tinatanggap ng server ang kahilingan sa imbakan, dinadala ng koneksyon ng datos ang mga byte, at naaabot ng paglilipat ang huling positibong tugon. Mas kapaki-pakinabang ang paghahambing ng mga yugto kaysa paghahambing ng mga kliyente, dahil ang pag-log in na gumagana at ang pangalang file na lumilitaw ay parehong humihinto bago ang finish.

Paunang tugon kumpara sa huling tugon

Para sa STOR, ang tugon na 125 o 150 ay paunang. Sinasabi nitong handa ang server na subukan at may koneksyon ng datos na binubuksan, hindi na umiiral ang bagay sa huling anyo nito. Kumpleto lamang ang operasyon kapag naabot ng paglilipat ang positibong tugon ng pagkumpleto, karaniwang 226 o 250, sa konteksto ng operasyong iyon.

Ang 426 ay nangangahulugang naabort ang paglilipat, at ang numerong inilabas ng ibang utos ay hindi resulta ng pag-upload na ito. Basahin ang tugon na kabilang sa STOR na iyon, hindi ang huling numero sa screen. Kung umalis ang kliyente bago dumating ang tugon na iyon, wala kang anumang ebidensya ng pagkumpleto.

Koneksyon ng kontrol kumpara sa koneksyon ng datos

Ginagamit ng pagpapatunay at listahan ng direktoryo ang koneksyon ng kontrol. Ginagamit ng mga byte ang hiwalay na koneksyon ng datos, at ang dulong punto nito ay pinag-uusapan sa bawat paglilipat. Ang matagumpay na pag-log in ay nagpapatunay ng daan ng kontrol at walang sinasabi tungkol sa kung naaabot ang address ng datos mula sa kliyente.

Kapag hindi mabuksan ng server ang koneksyon ng datos, siyasatin ang pinag-usapang dulong punto at ang pinapayagang daan. Kailangan pa rin ng passive mode ang magagamit na address ng datos at port, at ang firewall o kagamitang NAT sa pagitan ng kliyente at server ay maaaring magpadaan sa sesyon ng kontrol habang hinaharang ang saklaw ng datos. Kapag tinanggihan ng server ang kahilingan sa imbakan, tingnan ang pangalan ng malayong daan, mga pahintulot o mga hangganan ng imbakan. Wala sa dalawang sangay ang naipapaliwanag ng pagkakapapatunay ng koneksyon ng kontrol.

FTP sa TLS kumpara sa SFTP

Ang FTP sa TLS ay FTP pa rin: dalawang koneksyon, mga tugon ng FTP at upgrade ng TLS sa bawat isa. Ang SFTP ay isang subsystem ng SSH na may isang koneksyon at lubos na ibang set ng utos. Nagbabahagi sila ng layunin at halos wala nang iba, kaya ang pagsusuring tumatawid sa dalawa ay karaniwang nagsisimula sa paghahambing ng maling mga log.

Huwag patayin ang TLS para masuri ng tagapamagitang katulong ang sesyon, at huwag ituring ang kabiguan ng SFTP bilang problema sa tugon ng FTP. Kung kailangan mo ng scripted na pagsubok, manwal ng curl ay nagdodokumento ng hayagang TLS, passive mode at mga opsyon sa pag-upload, at ito ang sanggunian sa kung ano talaga ang binabago ng bawat flag.

Piliin ang protokol na aktuwal na iniaalok ng serbisyo bago ito i-debug. Ang server na nagsasalita lamang ng SFTP ay hindi kailanman gagawa ng tugon na 226, gaano man na-configure ang kliyente.

Nakikitang pangalan ng file kumpara sa nakaimbak na bagay

Ang nakikitang pangalan ng file ay maaaring kumatawan sa hindi kumpletong bagay, lalo na pagkatapos ng naabort na paglilipat o kliyenteng umalis nang maaga. Hilingin sa may-ari ng serbisyo na ihambing ang laki ng nilalayong test file at ang pinagkakatiwalaang hash ng nilalaman sa nakaimbak na bagay kapag inaasahan ang pangangalaga ng byte.

Ang binary at ASCII mode ay isa pang paghahambing na nagbabago ng resulta. Maaaring isalin ng ASCII mode ang mga dulo ng linya, kaya iba ang nakaimbak na byte kaysa sa lokal na file kahit nagtagumpay ang paglilipat. Panatilihin ang binary mode para sa checks na byte-bawat-byte, at huwag magdagdag ng mga opsyon sa conversion para magmukhang iba ang nabigong paglilipat.

Maaaring palitan ng ordinaryong STOR ang umiiral na file, at ang pahintulot na mag-log in o maglista ng direktoryo ay hindi nagtatatag ng pahintulot na gumawa o magpalit ng bagay dito. Gumamit ng malayong pangalan na hindi pa nagamit para sa pagsubok.

Ano ang ihahambing bago subukang muli

Huwag magdagdag, magpatuloy o mag-ulit ng pag-upload nang walang pag-iisip sa isang hindi tiyak na partial file. Sumang-ayon sa may-ari kung magsisimula muli sa bagong pangalan, gagamitin ang suportadong pamamaraan ng pagbawi ng serbisyo, o aalisin ang nabigong test object.

Isulat ang resulta bilang isa sa apat na pahayag: nabigo ang lokal na pagbasa, tinanggihan ang imbakan, naabort ang paglilipat ng datos, o nakumpleto ang paglilipat at tumugma ang nakaimbak na byte. Ang talaang iyon ay mas matibay na resulta kaysa sabay na pagbabago ng shell, VPN at mga setting ng FTP hanggang lumitaw ang pangalan ng file, at sinasabi nito sa susunod na tao kung aling yugto ang sisiyasatin. Itago ang nilinis na teksto ng tugon kasama ng pahayag na iyon. Kung gayon, ang muling pagsubok ay isang desisyon, hindi isang repleks.